[ocaml-platform] Changes to my previous proposal for namespaces

[Leo White]

>> The problem is with shadowing where the order between definitions is not
>> well specified.
>
> I would argue that this should push us towards making namespace-opens
> well-defined in order by default.  I think that opening namespaces on
> the command-line should be viewed as a largely second-class operation,
> and it would make sense in my mind to restrict it to a single
> namespace, which goes before everything else.
>

While the order of command-line namespace opens is another area where
shadowing may be risky, they are not what I am referring to here.

>> It is useful to be able to specify a namespace across multiple
>> locations, for instance within two separate search path files. The
>> ordering between "automatically opened modules" specified across these
>> multiple locations will not be well specified (probably depending on the
>> workings of your build system). This makes shadowing much riskier.
>
> I see.  This is low on my list of priorities.  I would be happy to
> require namespaces to be specified all at once in a single location.
> That would ensure that namespaces always have a unique definition,
> which seems to make life simpler.

Only for supporting multiple "automatically opened modules".

> But in any case, as long as namespace opens are well-defined and the
> namespaces are well defined at the time of the open, I don't see the
> problem.  

Namespaces opens will be well-defined in the sense that they will have
some kind of order. But that order may well depend on the workings of
their build system, so they are not well defined in any meaningful
sense.

>>> I basically don't see where your belief that automatically opened
>>> modules are semantically problematic and uncomposeable arises from.
>>> Certainly, my experience with packed modules argues in the other
>>> direction. Do you propose to delete the possibility of shadowing from
>>> the module language as well?
>>
>> Modules are defined in a single location, and can only be composed using
>> "include" statements. These include statements have a clearly defined
>> ordering.
>
> Why can't we have the same clear ordering everywhere for namespaces?
> What's wrong with having namespaces take on the same kind of ordered
> semantics that modules have?

This would require namespaces to have closed definitions. This would
require a completely different model from the one I have proposed. It
would be less flexible, less powerful, less lightweight, and probably
harder to use. In exchange you would be able to safely define multiple
auto-opened modules for each namespace (which I don't think anyone has
actually asked for).

> My main criticism of all of this line of thinking is that it seems
> like we're looking for a break of semantics between namespaces and
> modules, rather than accepting such a break to the degree it comes
> necessary.

A closed definition is one of the constraints forced on modules by their
need to be represented at run-time as a record. One of the motivations
for namespaces is to provide a system for containing modules that is not
bound by these restrictions. I don't see it as looking for a break with
the semantics of modules, so much as implementing a more flexible
semantics than what is possible with modules.