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

[Yaron Minsky]

On Tue, Feb 26, 2013 at 10:28 AM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> 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 believe that's right.  When you're reading Core's documentation,
much as when you're reading Core's code, you want to see the
in-namespace names.

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

I think if you've opened the Core namespace in prefernce to the Stdlib
one, you want to see Core_list as List, and you want to see
Stdlib_list as Stdlib_list.

Core should be able to stand up as a full-fledged alternative to the
standard library.  No one wants error messages for the standard
library to suddenly get twice as long because it's littered with
qualifiers.  We want the same for Core.

I would argue that when referencing identifiers in other namespaces,
you should at that point have the namespace qualifier in place.

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

I think you're underselling the importance of keeping names concise.
We've started using Garrigue's short-paths patch, and it is amazing
how much it helps error messages, and the key thing it does is remove
unnecessary qualifications.  OCaml's error messages aren't great as
they are, and making them even longer is a bug user-interface mistake.

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

I agree that having unique names that are accessible from any context
is good, though I think namespaces could provide this.  You could
refer to Stdlib#List anytime you needed to be explicit, and just use
List when you did not.

That said, I agree that your proposal provides this feature as well,
and that it's a good thing.

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

That's an interesting point.  Maybe we could do the same.

> 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