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

[Martin Jambon]

On Mon 18 Mar 2013 12:18:14 PM PDT, Martin Jambon wrote:
> On 03/18/2013 10:27 AM, Leo White 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).
>
> [pardon me if this has been discussed before, I'm just jumping in the
> conversation and likely don't understand all the issues]
>
> I don't think it would require namespaces to have closed definitions,
> which would defeat their purpose. It would only require to know which
> libraries are being *used* by the current source file (library =
> ordered collection of modules within the same namespace; different
> libraries can use the same namespace).

different libraries can *belong to* the same namespace.

> The following seems fairly natural to me:
> 1. have an "import" keyword or similar for specifying which libraries
> are being used, the order of the imports defining module order
> 2. open namespaces and modules at will

We actually wouldn't open namespaces at all, as noted in what follows.

> Point 1 defines locally the order of the visible modules without
> requiring the namespaces to be closed. Also, it makes the program's
> dependencies explicit and makes standalone programs self-buildable.
>
> import Theirnamespace.Theirlibrary
> import Othernamespace.Otherlibrary
> import Theirnamespace.Somelibrary
>
> (* assuming:
>    - auto-open of the above libraries
>    - no such thing as "open namespace"
> *)
>
> open ModuleA
>   (* look for ModuleA it in Theirnamespace.Somelibrary,
>      then in Othernamespace.Otherlibrary and finally in
>      Theirnamespace.Theirlibrary *)
>
> open Othernamespace#ModuleA
>   (* open ModuleA provided by Othernamespace *)