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

[Yaron Minsky]

On Tue, Feb 26, 2013 at 5:17 PM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> On 2/26/2013 8:48 PM, Yaron Minsky wrote:
>>
>> In short, I'd like to keep the things that affect the meaning of my
>> program largely in the source.  I agree that for very pervasive
>> things, like Core.Std or sexplib within Jane Street, you may want to
>> make this silently present at the build-system level.  But most of the
>> time, you want to be explicit about this kind of change to the
>> semantics of your program.
>>
>> Maybe the main difference between us is this: I want to use namespaces
>> for multiple libraries, not just highly pervasive ones like Core.  You
>> think of namespaces as a thing to solve the fairly narrow problem of
>> Core.  If I thought you were right about this, I would agree with the
>> rest.
>
>
> I think we agree on why we disagree.  For me, the only problem which is
> serious enough to justify changes to the language and toolchain is about
> name clashes (not being able to use two libraries together because they
> happen to use identical module names).  A simple non-technical solution
> exists today: a policy to avoid such clashes (long names). The only cases
> where this is problematic, I believe, is for big libraries used in a
> pervasive way, for which (i) long names become really tedious for the users;
> (ii) module aliasing is not enough because the library has many modules.

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.

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.

> I think this is fairly limited and can be solved by very light
> additions to the toolchain, allowing basically to define "user-land
> stdlibs" (with a context-dependent definition of what a stdlib is).
> I consider other use cases and "required" features of namespaces as
> nice to have (or not) but not important enough to justify any
> serious addition to the language definition and adaptation of
> existing tools, especially when we are talking about breaking some
> current invariants and properties on which some existing users might
> rely.

I understand where you're coming from, but I don't think it's the
right decision for the future of the language.  I think this is case
where OCaml can and should change.

y