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

[Leo White]

> Leo's main argument is that systematically using Pervasives is more
> predictable for users (that may not want to have to look at namespace
> descriptions to know which compilation units will be opened by
> default).

That's certainly an argument, but it is not my main one.

> I'd say in practice it's rather obvious at medium scale (for any given
> software project) which module is meant to be the
> Pervasives/Std/Prelude one, and large scale composability by default
> could be a better choice.

I don't think I've actually suggested providing any means for defining a
new namespace as the composition of existing namespaces. Nor do I have
any particular use cases for that feature.

However, my proposal does allow a namespace to be specified across
multiple locations, and it is important that these specifications are
composable.

The ordering between these separate specifications will inevitably be
under-specified, depending on things like the order of command-line
arguments. That means that any semantics relying on that ordering will
be potentially fragile. The best we can hope to achieve is to make sure
that conflicts between specifications are as obvious to the user as
possible.

We are discussing two possible semantics for "automatically opened
modules":

1. Supporting a list of auto-opened modules. The automatic open of these
   modules is morally equivalent to merging their contents into a single
   "Pervasives" module and then opening that module.

2. Only supporting a single "Pervasives" module. Trying to specify two
   "Pervasives" modules will simply result in one of those modules being
   chosen ahead of the other.

Of these two semantics, the second one is much more likely to bring
conflicts to the attention of the user. The first one is more likely to
hide accidental conflicts resulting in potential bugs. 

The second semantics also ensures that conflicts between namespace
specifications only occur at the level of whole compilation units,
rather than at the level of individual values and types.

In summary, any semantics for "automatically opened modules" will not
compose well. So it would be better to provide a system that obviously
doesn't compose than to provide a system that pretends to compose, and
may hide potential bugs.