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

[Christophe TROESTLER]

On Wed, 27 Feb 2013 07:58:41 +0100, Gabriel Scherer wrote:
> 
> I don't like your lazy initialization scheme because it changes the
> observable semantics of the the OCaml language when modules have
> global side-effects. Currently, the effects are evaluated in the
> linking order of the modules, not the use order.

For practical purposes this lazy initialization scheme may be
restricted to packed modules and module aliasing ("module A = B" where
neither A nor B is not used by other values — this is already
detected — in the module and B belongs to a packed unit).  I do not
think that people rely on the command line order for packed modules or
even for .cm[x]a libraries.  In the case order matters because of
dependencies, this would be tracked and compilations units would be
topologically ordered w.r.t. this dependency graph so this would be an
added bonus for the user.

> Note that the main difficulty of your proposal is to track
> dependencies at a structure item level, rather than at a compilation
> unit level as is currently done.

Not if we limit it to packed modules — you already have the cmo/cmx
and in this context I see packing as putting them in a .cm[x]a and
adding a module with submodules pointing to (aliasing) these
compilation units.  These pointers would actually be initialized (and
trigger linking) on actual usage.  [If this was adopted, I think
nobody would object if packing generated a cm[x]a instead of a
cmo/cmx.]

> Lazyness is arguably bad and in any case not needed if you have this
> finer granularity

Would you mind to explain?

> -- but as I argued this would have large, and possibly unpleasant,
> implementation implications.

I can't argue on that — not knowing much about the compiler internals.
However, it naively seems to me that the proposal relies on many
things that already exist.  Is is possible to have a more detailed
description of why the changes would be so invasive?