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

[Alain Frisch]

On 2/21/2013 7:39 PM, Leo White wrote:
> More generally, almost all naming systems are hierarchical. It is a
> tried and tested way of organising things.

The namespace system I've used most, XML Namespaces, has flat qualifiers 
(we could argue that they are in general URL/URN, with a hierarchical 
structure, but namespaces are really just strings matched with strict 
equality).

I agree with Xavier that if we give a hierarchical syntax to namespaces, 
this should somehow be reflected in the semantics to avoid confusion.

> Is it really so tedious for the compiler to look in multiple .cmi files
> until the right one is found?

Nothing is really tedious for a compiler, but there are technical 
drawbacks of doing so:

  - Performance:  looking up and opening files takes time, especially 
under bad OS such as Windows.

  - It prevents from putting .cmi files from many libraries in the same 
directory, which is sometimes useful (to simplify deployment; to control 
precisely the set of .cmi available for a given file; to improve 
performance by avoiding repeated lookups in many directories).

  - Spurious dependencies: technically, since the compiler will open 
them, all x.cmi files in the search path should be considered as 
dependencies for a module which refers to X.  This is necessary to have 
a correct notion of dependency for the build system (formally, each 
x.cmi could become the "correct one" if its namespace changes in the 
source file; and since all these files are opened, they should not be 
overwritten in parallel).  This complexifies the build system, 
especially for parallel builds, and creates a risk of dependency cycles.


> I also think that long filenames *are* tedious, if they weren't people
> would use them already. If you are using a large library, even with a
> good aliasing feature, you would end up writing:
>
>   open Core_Std_Mutex as Mutex
>   open Core_Std_Thread as Thread
>   open Core_Std_Date as Date
>
> at the beginning of all your files, instead of writing:
>
>   open Core.Std

That's why I've proposed to allow specifying mapping between references 
to external modules in dedicated files.  We could have a file 
core_std.ns (probably shipped with Core) with this content:

Mutex = Core_std_mutex
Thread = Core_std_thread
Date = Core_std_date

and just a reference in the source code (or on the command-line):

   open namespace Core_std

which would load core_std.ns and use the corresponding module renaming 
in the rest of the module.

Regards,

Alain