[ocaml-platform] Followup to Leo's proposal

[Yaron Minsky]

On Wed, Mar 13, 2013 at 1:03 PM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> On 03/13/2013 05:29 PM, Leo White wrote:
>>
>> In the unlikely event that there is a conflict, a simple namespace alias
>> like:
>>
>>     open namespace Xml as BaseXml
>>     [...]
>>     open namespace Core
>>     open namespace BaseXml
>>
>> or a user-written search path file that doesn't define the Xml
>> sub-namespace of Core would solve the problem.
>
>
> Since I've not seen a convincing case where hierarchical namespaces actually
> bring something useful, I maintain that the risk of having situations as
> above is sufficient to reject them.
>
> If Core needs to be extendef with a Xml "sub-namespace", let's use the flat
> name "Core_Xml".  If people want to open them, they have "open namespace
> Core_xml".  If they need to occasionally access components of this
> namespace, they can write "Core_xml#Parser.run".  If they don't want to open
> it but still is use frequently, they can alias it "open namespace Core_xml
> as Xml".

I agree that I see no big advantage to hierarchical namespaces.  But
most of the problems that show up here seem to be related to trying to
keep an unordered semantics, which to me seems like a mistake.

OCaml's environment-manipulating operations by and large have an
ordered semantics, and I think it's a mistake to make namespaces
different.  People seem very afraid of shadowning, but OCaml already
has shadowing in the module language, and our experience as very heavy
users of the module system is that judicious use of shadowing is very
useful.  For example, the ability to extend modules using `include`
and shadowing is highly convenient, i.e.:

    include List
    let map ~f x = ...

We'll combine this shadowing with a similar version at the package
level, by writing this:

   open Core.Std
   open Core_extended.Std

where Core_extended shadows Core.Std.List with Core_extended.Std.List,
where the latter is an extended version of the former.

My basic feeling is that ordering and shadowing is a feature, not a
bug.

To be clear: opens have serious downsides.  They should be legal, but
rare.  But when they do show up, their semantics should be ordered.

> (Btw, I find it ugly to use "open" for an aliasing feature.  We
> need a better syntax!)

Indeed!

>> Actually, I think that "ocamldep -modules" has the property that it will
>> return the full module name of any possible dependency that the file
>> could have under any possible search path. By default I would leave this
>> as it is so that:
>>
>>      open namespace Foo
>>      Bar.use
>>
>> would produce "Foo#Bar" and "Bar" as possible dependencies. This is the
>> same as it currently does for sub-modules of opened modules.
>
>
> What about:
>
>  open namespace M1
>  open namespace M2
>  Bar.use
>
> ?
>
> Even with the "shallow" semantics, "ocamldep -modules" cannot know if there
> is (or will be) a namespace M2.  So do we get "M1#Bar", "M2#Bar",
> "M1#M2#Bar" and "Bar" as possible dependencies?   The size of the output
> grows exponentially in the number of "open namespace"!
>
>
>
> Alain
>
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform