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

[Yaron Minsky]

On Tue, Feb 26, 2013 at 10:38 AM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> On 02/26/2013 03:30 PM, Yaron Minsky wrote:
>>
>> One thing I'll say is that it is important to be able to add values,
>> and not just modules, to the namespace.  Open Core.Std also adds
>> top-level values, as does the traditional standard library (i.e.,
>> Pervasives), and I don't want to lose that.
>
>
> I can understand that this is nice, but is it really important?

I think it is important.  Part of what we're doing in thinking through
Real World OCaml is to figure out what we can do to make using the
system as easy and painless as possible.  Requiring two separate
declarations is asking people to forget one of them (and from the
comments we've gotten from people alpha-testing the book, they make
these mistakes quite a bit.)

The build system I think is just the wrong place to specify this.  You
should be able to control your namespace conveniently from the source.
Specifying implicit opens from the build system is just asking for
people to be confused about how their namespace is controlled.

> Concretely, we are talking about the necessity to add an extra "open
> Core_std" statement in addition to the namespace opening statement (or a
> corresponding command-line option).  Does this extra open statement justify
> to make concepts less orthogonal?
>
> My "flat mapping" proposal could be extended to support "implicit opens" in
> the same mapping files (in addition to lines like "List = core_list", we
> could have "open Core_std" lines).  I don't think it is a good idea to do
> so, however (and it would require to have two versions of the mapping file,
> one to be used inside the implementation of Core itself and another one for
> client code -- without the open statement).  We could also let the user
> specify implicit opens on the command-line, so as to push the problem to the
> build system or ocamlfind.  Again, I'm not sure this is a great idea to do
> so, but at least, it would make it clear that this feature is not related to
> the module naming system.
>
>
> Alain