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

[Alain Frisch]

On 02/26/2013 03:38 PM, Yaron Minsky wrote:
> - UNSANITARY: Having both "open namespace Core.Std" and Core_List as
>    names seems a little unsanity.  Indeed, to provide a decent user
>    experience, you probably want to hide the Core_List name almost
>    everywhere.  You don't want it showing up in error messages,
>    documentation, source files, etc.  When you need to do a bunch of
>    work to hide something, maybe it's better not to include it at all.

Concretly, what should the OCamldoc-generated page for a Core module 
look like?  Should the reference to types defined in other Core modules 
be displayed without any indication that they come from Core (without 
clicking on it)?  I would find this very confusing.  Similarly for error 
messages: it is indeed nice to be able to see List instead of Core_list 
when you live with Core all you day long and there is no ambiguity. 
Still, there needs to be a way to have a more explicit error message, 
which could distinguish Stdlib_list from Core_list.  For me, seeing List 
instead Core_list in "common cases" is only nice to have (and definitely 
achievable with a little more effort in my proposal), but being able to 
distinguish Core_list from Stdlib_lib is crucial.  (And I don't think 
that showing Core#List is nicer than Core_list, at least not enough to 
justify the addition of a new notion.)

Having long unique names which can be used in any context is a very good 
property and would also avoid problems reported with camlp4 extensions 
not being able to access a specific "standard" module.  If we can use 
Stdlib_list in any context, we don't need to do any hack to refer to it.

> - NO HIDING: I'm not sure that the other namespace proposals do
>    support this, but I'd like to be able to hide some modules so that
>    they are not reachable outside of the namespace.  We can do this
>    with the current Core.Std, but I don't see how to do it in Alain's
>    proposal.

If the library does not install the .cmi file of the private module, it 
cannot be accessed by any "client code".  We do this regularly for our 
internal libraries.  For me, this is not really related to namespaces.

With my proposal, it is even better: you can install .cmi files so that 
some "privileged" parts of your code base can still access it, but also 
restrict access to other parts by providing a mapping file which does 
not alias the private module (and just arrange so that you don't have a 
-I on the directory where the .cmi is installed).  Currently, what we do 
to achieve it is to have several install directories for some libraries 
and copy a different subset of .cmi files to each of them.


Alain