[ocaml-platform] Followup to Leo's proposal

[Leo White]

> I think what you've come around to is pretty similar to what I had
> intended in the first place when I was saying "auto-open modules".  In
> particular, you're proposing having a module "Core" associated with
> the namespace "Core", and that the two are automatically opened
> together.  My thought was to do something that is only slightly
> different from that: to be able to associated a list of modules L with
> a namespace N, such that opening N automatically opens L.  That seems
> broadly speaking less confusing and more flexible, rather than relying
> on name collisions.

The problem with having a list of auto-opens is that definitions in one
open may conflict with definitions in another open. This forces us to
give an ordering to the list. If the namespace is defined across
multiple parts of the search path then this ordering will be quite
fragile. The fragility of this ordering will probably go unnoticed until
there is a mysterious bug/compilation error. By relying on name
collisions, it makes it clear to people that there should only be a
single such module (just like other modules), and any conflict is likely
to become apparent immediately.

> I think this specifies the role of modules in "open namespace N" and
> "let open namespace N in expr".  What seems to be in contention is the
> semantics of N#M.  I think Leo and Alain are proposing that this be
> limited to M being another module or namespace, and that it would
> ignore the module opens.  I would have thought it more natural for N#M
> to translate to "let open namespace N in M", so that M could be either
> a module or a value, and could be present in the namespace N or in the
> list of modules that is auto-opened with N.
>
> What is the argument in favor of the semantic distinction between N#M
> and "let open namespace N in M"?

I'd think of it more as keeping the distinction between "N#M" and
"N.M". 

If you allow the M in N#M to be a value or type then namespaces go from
being a simple system for naming compilation units to being a partial
replacement for modules. This overlap will cause confusion, users should
never be in a position of wondering whether they should make something a
module or a namespace; it should be obvious from what that thing
contains.

Currently, given an environment and a module expression (e.g. N#M or
N.M) the compiler knows exactly where to find the module (e.g. as member
M of the N namespace). If you allow N#M to mean both a sub-module of an
auto-opened module in N and a member of N then the compiler must look
inside any auto-opened modules of N to figure out where the module
is. This also adds a dependency on the auto-opened module even if it
isn't used.

Another possible benefit of using name collisions to associate the
"Core" module with the "Core" namespace, is that it could be used to do
"auto-opens" as syntactic sugar. For example we could allow something
equivalent to:

  open Core   (* opens the Core module *)

  open namespace Core (* opens the Core namespace *)

  open namespace and module Core  
             (* equivalent to open namespace Core;; open Core *)

Obviously the syntax should be less verbose, but the point is that this
could make the "auto-open" explicit in the source while still keeping a
convenient syntax.