[ocaml-platform] on the need and design of OCaml namespaces

[Leo White]

>This seems a little bit hackish to me, and likely to require more 
>over-engineering (do we need a tool to create those .cmi files; if they 
>are plain text file, it's ugly to use the .cmi extension).

I'm still not sure that they are really needed, but if they are the 
simplest thing to do would be to automatically generate some kind of 
"core.std.cmn" file whenever an mli file was compiled that contained "in 
Core.Std". This would basically indicate that a "Core.Std" namespace 
existed and that some ".cmi" files in this directory used it.

>We use this quite intensively on LexiFi's code base.  This really speeds 
>up compilation time under Windows, and we also use it to simplify 
>deployment (our application is shipped with some .cmi files from many 
>libraries and automatically compiles user-provided addins against them; 
>it would be tedious -- and useless -- to reproduce a complete hierarchy 
>of libraries on the installation side).
>
>We would hate to have the third-party libraries we use adopt a new 
>feature (namespaces) which solves a problem we don't have but forces us 
>to change in non trivial ways how we organize our code base and deployment.

It is quite a specialised case, but I don't think it would be too hard to 
accommodate. If the compiler accepted filenames like "list.1.cmi" as 
possible files containing a "List" module, then you could safely put all 
your files in a single directory.

>> This is basically an error, so dependencies
>> should not be expected to be correct.
>
>I don't agree.  Having wrong dependencies is a nightmare to debug and 
>during development having errors in the code is not an exceptional 
>situation.  A robust build system should handle nicely things like 
>moving files around, renaming them, etc.

I didn't mean that the build system wouldn't detect the error only that it 
wouldn't detect it until dependencies were recalculated.

>Imagine you have a big 
>project with two modules
>
>   foo/a.ml in namespace Foo
>   bar/a.ml in namespace Bar
>
>Now you compile x.ml which refers to Foo # A. "ocamldep -modules" 
>reports that the dependencies for it include mode "A", which must be 
>mapped to all buildable a.cmi/a.cmx in your tree, i.e. both foo/a and 
>bar/a.  (Things are even worse if you use the same syntax as for 
>modules, because then any reference like Foo.A must be interpreted as a 
>potential dependency to foo.cmi/cmx or to a.cmi/cmx.)  But maybe 
>bar/a.ml refers to x.ml, and then you have a circular dependency.

This won't a problem if you use a build system specialised for OCaml, since 
they would know about namespaces and create the following dependencies:

x.ml: Foo#A
Foo#A: foo/a.ml
Bar#A: bar/a.ml

Even the makefile output of OCamlDep could be modified to avoid this 
problem using phony targets, although it is probably not worth it.

>I'd like any proposal about namespaces to come with a description of (i) 
>how ocamldep is supposed to behave; (ii) how build systems (based on, 
>say, make, omake and ocamlbuild) are supposed to be adapted.

For namespaces:

 - Whenever ocamldep encounters a line "in A#B" within c.mli then it creates
   a dependency "A#B#C: c.mli".

 - Whenever it finds a use A#B#C in a file e.mli it creates a dependency 
   "e.mli: A#B#C".

 - Build systems are modified to include support for phony namespace 
targets.