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

[Alain Frisch]

On 02/26/2013 11:29 PM, Yaron Minsky wrote:
> I think the reason we disagree ties to questions of scale.  We have a
> number of projects that are big enough to want to build their own
> "pervasive" library.  For example, we have a library whose purpose is
> designing trading systems.  It has its own Std and its own set of
> conventions, and many thousands of lines of code built within that
> world.  We also have a separate library whose purpose is building user
> interfaces for trading systems.  It too has its own Std and its own
> conventions that it wants to standardize on.
>
> Namespace control becomes a real issue in this world quite quickly.  A
> solution designed for one hulking Stdlib replacement doesn't address
> enough of the problem space.

But isn't it the case that in a given part of the project (say, a 
subtree), the code depends on a well-defined number of those libraries, 
and this information is already part of the build system?  If this is 
the case, I suppose that most modules starts with a few global "open 
Foo.Std" statements, so Foo.Std and Bar.Std cannot really share any 
common internal names (or you have to revert to using fully qualified 
names).  I don't see why my proposal would not cover those cases.  It is 
true that I'd probably prefer to use directly long names in LexiFi's 
projects (as we currently do), maybe because of a question of scale, 
maybe because this is a case where I think being more explicit is a good 
thing.  But I don't think my proposal would prevent to do what you want.

> And I don't think these scale issues are Jane Street only.  A big part
> of the goal of the work we're putting in to OCamlLabs and Real World
> OCaml and these working groups is to really grow the OCaml community,
> and for that, OCaml needs to get good at programming-in-the-large.  I
> think good namespace control is a key part of doing that right.

Maybe this is indeed a matter of scale, but the desire to scale in 
itself is not a good justification for a new feature (especially if it 
breaks current properties); a good justification might be to address an 
issue which prevents smooth scaling.  I thought the only serious issue 
was name clashes of modules in different libraries.  I still believe 
that very light namespace control (simple "flat" control over the 
reference->unit mapping) is enough to address this.  During the 
discussion I've seen several other "requirements" (avoiding some "open" 
statements, having extensible namespaces, organizing modules/namespaces 
in a hierarchy), but to me they address problems created by the 
assumption that we must introduce a notion of namespace, not by actual 
problems which currently limit scaling or user-friendliness of the language.

This is not really in contradiction with your position, since your 
mentioned my proposal as one which might be sufficient to you.  But I'd 
like proponents of more advanced stuff to describe which actual problems 
are addressed by their proposal (with arguments not assuming that the 
notion of namespaces is an interesting addition to the language
on its own).

Maybe a good way to move the discussion forward would be to agree first 
on which problems we are trying to solve (and whether they are related 
to scaling, to beginner-friendliness, to tool-friendliness [like 
ocamldoc], etc).

Alain