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

[Leo White]

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