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

[Yaron Minsky]

On Mon, Mar 18, 2013 at 1:27 PM, Leo White <lpw25 at cam.ac.uk> wrote:
>>> 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.

I think I understand your point now.  I don't have any objections
really to the semantics you propose here.

y