[ocaml-platform] on the need and design of OCaml namespaces

[Leo White]

>That's an interesting take on this.  Would you care to elaborate on
>why a module approach may not be sane?  Is it from a semantic or an
>implementation point of view?

Ignoring the implementation issues for now, consider the run-time semantics 
of the module system.

At run-time a module is a record. Initialising a module involves 
initialising every component of the module and placing them in this record. 
Initialising these components can involve executing arbitrary code; in fact 
the execution of an OCaml program is simply the initialisation of all its 
modules.

The problems with pack are related to these dynamic semantics. In order to 
be a module the "pack" must create a record to represent this module. This 
means that it must initialise all of its components. It is this (rather 
than any detail of pack's implementation) that causes the problems 
identified by Yaron and others.

Now, access to the components of a top-level module could proceed without 
the existence of this record. However, the record is required in order to 
"alias" the module, use the module as a first-class value or use it as the 
argument to a functor.

Any attempt to overcome the problems with pack, whilst still maintaining 
the illusion that the "pack" is a normal module, would result (at the very 
least) in one of the following unhealthy situations:

- The module type of the "pack" module would depend on which of its 
  components were accessed by the program.

- Any use of the "pack" module other than as a simple container 
  (e.g. "module CS = Core.Std") could have a dramatic effect on what was 
  linked into the program and potentially on the semantics of the program.

Namespaces are basically modules that can only be used as a simple 
container. This means that they do not need a corresponding record at 
run-time (or any other run-time representation). This avoids the problems 
with pack as well as enabling other useful features (e.g. open 
definitions).