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

[Leo White]

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

This is by design. This feature is only meant to provide support to
specialised libraries, like Core, that wish to provide their own
equivalent of the standard library's Pervasives module. We probably
don't want to encourage its general use. I don't think it will be a
problem that you can't easily compose the "Core" namespace with the
standard library's namespace.

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

This would be handled like two compilation units with the same name: one
would shadow the other and so only one would be opened. This is safer
than having both modules opened, since opening both may result in one
module partially shadowing another, which is more likely to go
unnoticed.

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

Despite Alain's concerns, I think that it will not be too difficult to
handle the tooling for hierarchical namespaces. However, I think it will
be easier to determine this once the tools have already been updated to
support flat namespaces.

Similarly, the design choice of shallow merging vs. deep merging for
opening hierarchical namespaces may be easier to reason about once
namespaces have been included in the language.

These two issues are important, and require some thought before making a
full proposal including hierarchical namespaces. Rather than waiting for
these issues to be resolved, I would rather proceed, in the short term,
with a proposal for flat namespaces.

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

In my proposal modules must still have a unique name. This name will be
reflected in the filename of the ".cmi" file (e.g. Foo#Bar as
foo-bar.cmi). To avoid long source file names, the name can be specified
with the "-name" command line argument.

Since I expect people to provide a namespace for their package, I would
expect the interface for module bar from package foo to be called
"foo-bar.cmi". If people don't use the same names for their packages
then this should avoid all naming conflicts.

An alternative mechanism, also supported by my proposal and useful for
libraries that are compatible with versions of OCaml without namespaces,
is to name the module bar in the package foo "foo_bar.cmi" and then
provide a search path file "foo.mlpath" that maps "Foo#Bar" to
"foo_bar.cmi".

Note that in both these solutions the source file can be named "bar.ml",
and the "-name" argument used to add the "Foo#" or "Foo_" prefix to the
name. Build systems could easily add automatic support for these
conventions.

If people wish to be extra careful then they can use the "-name"
argument to add whatever additional data they want to the module name to
ensure that it is unique.