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

[Alain Frisch]

On 02/25/2013 10:53 PM, Yaron Minsky wrote:
> I understand your point Alain, but while what you're saying is
> technically reasonable, I think it doesn't hold together.  When
> programming in the large, it is useful to be able to manipulate the
> namespace and group parts of the world together.

Can you give concrete examples of which manipulations are desired (and why)?

> Many libraries, not
> just Core or Async, want to be able to remap the world by adding a
> collection of related names to the namespace.  The ability to do the
> moral equivalent of:
>
>     open Core.Std
>
> is powerful and important.  Your proposal of having people add
> prefixes to module names does not fit the bill, and the resulting
> system does not, in my opinion, scale.

I believe my proposal covers this use case.  If you depend a lot on a 
specify library which exports many modules, you might indeed want to 
avoid using long names everywhere to access these modules.  That's why I 
propose to give simple ways to alias long modules names to short ones, 
in a way which can be factorized (with external mapping files).

In my proposal, the equivalent of "open Core.Std" would simply be to 
tell the compiler (through a command-line option or with a directive in 
the code) to use a mapping file.  The same can be done within the 
library itself.

Here is a minimalistic version of my proposal, restricted to specifying 
those mapping files on the compiler and tools command-lines.  To make it 
clear that this is only about mapping module references to compiled 
units, let's piggy-back the -I option.  If its argument is a file with a 
.ns suffix and not a directory, the compiler interprets it as a mapping 
file (a sequence of lines of the form "Module_name = 
relative_path_to_compiled_unit", e.g. "List = core_list"), and when this 
-I option is considered during the resolution of a module reference 
(such as "List") and the module is defined in the file, the compiler 
simply resolves the module to the corresponding unit.

This approach could also be used to restrict which units are visible by 
the compiler (and avoid repeated lookup on the file system) without 
moving files around on the file system.

ocamldep (without -modules) would apply the same logic; ocamldep 
-modules could either implement the same logic, or leave it to the build 
system interpreting its output (allowing more dynamic scenarios where 
the mapping file themselves are generated).  I expect ocamldoc to work 
mostly out-of-the-box, even though one could think about using the 
mapping files (in reverse direction) to provide shorter names in the 
generated documentation (or not).

Users of a library are never forced to use the mapping files, and they 
can always refer to a module with its full name (provided the 
corresponding -I <path> is used).

The OCaml stdlib would be adapted to use longer names (stdlib_list, 
stdlib_array, etc) and shipped with a stdlib.ns file opened by default 
(unless -nostdlib is used).  To be clear: this mapping file will be used 
by the stdlib itself, so references within itself don't need to use long 
names.

I'm interested to see concrete examples of manipulation or scenarios 
not be covered by this proposal.


Alain