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

[Gabriel Scherer]

The problem with this fixed-syntactic choice is that it hampers
composability of namespaces.

Assume you want to work with namespaces Foo and Bar at the same time.
In a hierarchical setting you can build a namespace with two
namespaces for Foo and Bar (eg. { A => Foo, B => Bar } ) and this has
very simple properties (no conflict/shadowing involved). In a flat
setting, or if you want to avoid adding one level of depth, you will
rather use (A merge B). What happens then if both A and B have a
Pervasives module?

(The semantics model of the previous email simply says that both
compilation units referred to by A#Pervasives and B#Pervasives should
be in the open list of the namespace (A merge B).)

I think there is a subtlety at play when you say that "open namespace
Foo in id" is not the same as "Foo#id" anymore. The "id" in "Foo#id"
may only be a compilation unit name (component). If "Pervasives" is a
module rather than a subnamespace, "open Foo#Pervasives" may introduce
only OCaml values, so in particular will not introduce new compilation
units in the environments. So the purported semantics difference here
is only a syntactical ambiguity: the meaning may change if you choose
"id" in a lexical class common to compilation units and submodule
names, and you see it as an internal module name in "open namespace
Foo in id" and a compilation unit name in "Foo#id": it's actually not
the same identifier.

(I still think it would be extremely fruitful to try to remove this
syntactic ambiguity between compilation unit names and submodule
names.)

Regarding the proposal as a whole:
- I'm curious and not sure: what is the reason to remove hierarchical
namespaces from your proposal? At first I believed it was the ongoing
tooling discussion with Alain, but he actually objects to
non-canonicity of names (as permitted by aliasing) more than your
foo-bar-baz hierarchical structure. Which perceived problems are
solved by this change?
- I believe the proposal is still inadequate, or at least
underspecified, with regard to the internal name conflicts problem.
What kind of conventions do you envision around your proposal to avoid
such conflicts?

On Fri, Mar 15, 2013 at 3:33 PM, Yaron Minsky <yminsky at janestreet.com> wrote:
> This proposal makes me happy.
>
> y
>
> On Mar 15, 2013 9:43 AM, "Leo White" <lpw25 at cam.ac.uk> wrote:
>>
>> Following recent discussions, I would like to propose some changes to my
>> previous proposal:
>>
>> ## Flat namespaces
>>
>> It has occured to me that, while I have some good use cases for
>> hierarchical namespaces, they are not critical for the *initial*
>> implementation of namespaces in OCaml. Essentially, I'm changing my
>> position from "We should include support for hierarchical namespaces" to
>> "We should make sure that we could easily add support for hierarchical
>> namespaces in the future".
>>
>> ## Pervasive modules
>>
>> I think that the simplest solution to Yaron's need for "automatically
>> opened" modules is to say that:
>>
>>     open namespace Foo
>>
>> will open the namespace Foo and then, if it exists, open the module
>> Foo#Pervasives.
>>
>> Members of Foo#Pervasives would not be accessible directly from Foo
>> (i.e. Foo#id != Foo#Pervasives.id).
>>
>> I think this has the following benefits:
>>
>> - This is basically a syntactic solution: we don't need to "dirty" the
>>   semantics or specification of modules with the issue of automatically
>>   opening modules.
>>
>> - Only one Pervasives is opened, so conflicts between separate
>>   specifications of a namespace should be obvious immediately. Its
>>   relience on a specific name also makes the potential for conflicts
>>   obvious to users.
>>
>> - It is clearly a bit of a fudge, which will discourage its excessive
>>   use, and prevent any percevied overlap bewteen namespaces and
>>   modules. This also makes it seem less "offensive" that it slightly
>>   breaks the idea that "let open namespace Foo in id" should be
>>   basically the same as "Foo#id"
>>
>> - It fits in with the standard library's use of Pervasives. You could
>>   consider current behaviour as simply opening the "Std" namespace
>>   before every program.
>>
>> I think that simple solution is better than trying to find a generalised
>> sematics for "automatic opens" in namespaces. As Gabriel's e-mail shows,
>> these semantics are non-trivial. I think that it is better to solve a
>> specific problem with a specific solution, rather than creating a
>> generalised solution for its own sake.
>>
>> Regards,
>>
>> Leo
>> _______________________________________________
>> Platform mailing list
>> Platform at lists.ocaml.org
>> http://lists.ocaml.org/listinfo/platform
>
>
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform
>