[ocaml-platform] Followup to Leo's proposal

[Leo White]

> Having
> namespace opening be a special-case thing that only happens on the
> file level and that is hidden from the source just seems like an
> unfortunate special-casing of a namespace manipulation tool (like let
> and open) that should be available generally.

Just to be clear I'm not proposing to have namespace opening at file
level, just the hidden opening of modules.

>>
>> I think the awkwardness is more related to how you treat things like:
>>
>>    Core#Foo
>>
>> where Foo might be a sub-module of Core#Common.
>
> Can you elaborate a bit?  Why is this case problematic?  I can kind of
> see why this is weird, but other than making an explicit requirement
> of having an ordered semantics (which to me seems like the right
> answer anyway, since it's more in tune with how OCaml's other
> namespace manipulation operators work), it seems fairly
> straight-ahead.  But I'm probably missing something important.

We should propbably stop calling this idea "auto-opening" because it is
really about allowing modules to be "included" within a namespace. This
is not a small change to the semantics. Without "auto-opens" namespaces
are simply a mechanism for controlling the names of compilation units,
with them they become a partial replacement modules: able to contain
values, types, exception, etc. Having two different features that
substantially overlap is normally a bad idea since it can cause a lot of
confusion.

Without auto-opens the namespace system is completely oblivious to the
actual contents of modules. With auto-opens the compiler must look
inside modules to work out whether "Core#Foo" refers to a member of Core
or a sub-module of one of its auto-opened modules.

Also, an ordered semantics is not for free. It makes having a
namespace defined in multiple places (as with users adding to existing
namespaces) much more fragile.

I think this is why people are reluctent to include automatically opened
modules in the namespaces proposal: it is quite a large change to the
semantics to handle a problem that is only likely to affect a few
libraries.

However, I think that I can see a way to avoid the problems of an ordered
semantics and possible "Core#Foo" conflicts.

The basic idea is to define a module named "Core" containing the values
that you would like automatically opened, as well as a namespace named
"Core". Then you provide some kind of opening operation that opens both
the namespace and the module named "Core".

This avoids the problem of ordering members of namespaces, since there
should only be one module called "Core". Technically there could be
multiple "Core" modules in the search path, but we simply use the first
one we find just like normal modules.

It also avoids the issue of "Core#Foo" conflicts, since "Core#Foo" must
refer to the "Foo" member of the "Core" namespace, while "Core.Foo"
would refer to the "Foo" sub-module of the "Core" module.

This could be added to a namespaces proposal in a number of ways. For
example we could allow modules named "Core#_" (or core-_.ml) to be
defined. These modules could be refered to directly in programs as
"Core". When the compiler encouters a "open namespace Core" construct it
first opens the "Core" namespace, and then it searches for a module
named "Core#_" and opens that as well.

Regards,

Leo