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

[Leo White]

>Yes, my initial proposal was about adding a "(local) namespace opening" 
>statement to the language:
>[...]
>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).

Without an open statement your proposal does not scale well. The main need 
for namespaces arises out of the fact that people choose the same short 
names for their modules. This will still be the case for the names people 
choose within their ".ns" files. As soon as I want to use two libraries 
that contain modules with the same short name, your proposal will have the 
meaning of the short name decided by the order of command-line arguments. 
This seems very fragile.

I also think that open statements (even at the top of a file) are a very 
good thing. They show which libraries the file is going to use. Currently, 
a file using a library that does not use pack will simply launch straight 
into using modules with short names that give no indication of their 
origin. I must look in the build system to find out what they refer to. By 
encouraging people to use namespaces, these files will instead start with 
"open namespace Foo", and it will be obvious what libraries they are using.

As OPAM (and the platform) become more widely used I expect there to be 
many more small convenience libraries. This will increase the number of 
libraries that are being used within a single project, and it will be 
useful to know from the source files themselves which files use which 
libraries. Up to now OCaml has cleverly avoided this problem by 
discouraging people from using each other's libraries.

>> 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.

I understand that for backwards compatibility it is useful to be able to 
use files via both a namespaced name and a traditional name. However, when 
not worried about backwards compatibility, we should instead be focussed on 
providing a coherent story about how OCaml components are named and how 
these names are managed. For me, this means (for a non-backwards compatible 
library) only providing (or at least actively encouraging) access to 
components through namespaces.

>> 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".
>>
>> [...]
>
>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).

These implicit namespaces are simply a convenience. If you are finding that 
executing ocamldep is taking an unwelcome amount of time then simply make 
your namespaces explicit by providing ".ns" files.

>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.

Firstly, I would like to make clear that this would be no problem for build 
systems that used makefile formatted ocamldep output.

"ocamldep -modules" has always produced an over-estimate of the modules 
that a file uses and then allowed the build system to figure out the rest. 
OCamlDep would simply treat any namespace for which it could find no ".ns" 
file as an implicit namespace. For any module that might be from the 
implicit namespace it would produce a (possibly spurious) dependency. Just 
like before, it would be the build system's job to know which dependencies 
were spurious.

It is not surprising that proposals to fix how OCaml maps names to files 
might require some changes to build tools. However, there aren't that many 
OCaml specifc build tools, they would only be small changes, and they would 
only be necessary for some of the build tools. More importantly there would 
be an extremely simple work around:

 If your build tool hasn't been updated to support implicit namespaces then
 write out the namespaces explicitly (i.e. create some very simple ".ns" 
 files).