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

[Alain Frisch]

On 2/26/2013 6:03 PM, Leo White wrote:
> 1. Alain's proposal does not include a notion of opening a namespace.
> The    ability to only open a namespace when actually using it (e.g. a
> local    open) would be very useful. For example, this means that the
> proposal    provides no assistance for handling multiple standard
> libraries in the    same program: you can either make "List" equal
> "Core_List" everywhere or
>     you can make it equal "Stdlib_List" everywhere. I see no real reason
>     why Alain's namespaces could not be extended with a namespace
> opening    feature.

Yes, my initial proposal was about adding a "(local) namespace opening" 
statement to the language:

   open namespace Core

   let open namespace Core in ....

(Both would look for a core.ns file on the search path.)

I've simplified it even further by restricting its use to entire unit 
and putting the directive it on the command-line instead of the source 
code.  If the need for controlling locally which namespaces are used is 
felt, I won't object to it.  But I'm not yet convinced that this is so 
useful (and it complicates things, such as decicing how to display a 
nice type name in case of type error, because this depends on the 
location in your module).

> 2. Alain's proposal provides no means of aliasing namespaces. Similar to
>     opening a namespace, it would be useful to be able to say "open
> Core.Std as CS" and then refer to Core_Std_Mutex as "CS#Mutex"

I believe that aliasing modules is what matters.  Since I don't 
understand the need for a dedicated notion of namespace yet (with some 
operations on namespaces) I also don't see the need for aliasing them.

> 2. A module's name depends on other files. A module's name (by which I
>     mean its namespaced name) depends on the ".ns" file, this could
> definitely be confusing.

I don't agree with this interpretation: the name of the module depends 
only on its file name, and we provide a convenient way for client code 
to refer to these modules with shorter names, locally.  It is a big 
advantage, for me, that client code could always be written without 
"namespaces", if required.

> 3. They require you to manage an ".ns" file. Not a major burden, but it
> is    one more place to look for errors. It also must be included in all
>     calls to the compiler.

For any serious use of the compiler with some third-party libraries, the 
command-line is not built by hand, but by your build system and/or 
ocamlfind.

> 4. To me they put the namespace information in the wrong place. A
> component should define its own names, it should also not have to open
>     its own namespace.

I guess this is a matter of taste, and corresponds to a conception of 
what namespaces should be as an identified notion, rather than solving 
an actual need or addressing a concrete problem with my proposal 
(correct me if I'm wrong).

> As a side note, if people are okay with long filenames, why not support
> having filenames like "core-std-mutex.mli" and then allow "open
> namespace Core" and "open namespace Core#Std".
>
> These could be treated as if there were automatically a "core.ns":
>
> namespace Std = "core-std.ns"
>
> and "core-std.ns":
>
> module Mutex = "core-std-mutex.mli"
>
> that were passed to any compiler invocation that had such files on its
> search path.

I don't like this implicitness: how can we infer dependencies?  If 
ocamldep sees a reference to "List" in scope where "open namespace Core" 
and "open namespace Bar" are both active, it would have to look for both 
core-list and bar-list files (and there will be a combinatorial 
explosion in the resolution if you allow opening nested namespaces). 
Worse: if we use "ocamldep -modules", this resolution has to be done by 
the build system, so this complex logic (which depends on the location 
in the source file) will have to be re-implemented in omake and other 
build systems around.  It is an important property that "ocamldep 
-modules" does not need to look for the existence of compiled units on 
the current tree.


Alain