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

[Martin Jambon]

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

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

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 *)


Martin