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

[Yaron Minsky]

On Mon, Mar 18, 2013 at 12:18 PM, Leo White <lpw25 at cam.ac.uk> wrote:
>> Just to be clear, do you agree with Gabriel's claim that that
>>
>> open namespace A
>> open namespace B
>>
>> will open A#Pervasives and then open B#Pervasives?
>
> Yes
>
>> As to your larger point, I basically disagree that the possibility of
>> shadowing implied by (1) is something to be avoided.  Module opens
>> behave this way, and within Jane Street we've used them extensively,
>> using limited, purposeful shadowing, for a decade, and to good effect
>> as far as I can tell.
>
> Shadowing is fine if the order of definitions is well specified. For
> example, module opens are clearly ordered by their position in the
> source file.
>
> 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.

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

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.  I would be perfectly happy for all module opens to happen
after all module aliases in a namespace if that simplifies matters.

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

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.

y