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

[Alain Frisch]

Consider the following piece of code:

  module X = struct let x = 1 end
  open namespace Foo
  let a = X.x

and assume that there is a module Foo#X.  Would X.x refer to this 
module, or to the one defined defined on the first line?

The least surprising semantics is probably the first one (opening a 
namespace can hide local modules), but the other one can also be 
justified by saying that namespaces only organize the lookup of 
compilation units on the filesystem, which is (currently) done only when 
modules cannot be resolved in the local environment.

Moreover, the second semantics has nice properties:

   (i) It is much easier to implement: one only needs to maintain a list 
of opened namespaces in the typing environment, to be used during lookup 
on the filesystem. I see only two ways to implement the first semantics:

     - Scan the search path for all foo-*.cmi files when processing the 
"open namespace" statement (i.e. use Sys.readdir, and not only 
Sys.file_exists as today), in addition to the search path files.  This 
would probably work ok with most current build systems, but it would 
prevent from doing "live" discovery of dependencies by instrumentation 
of system calls (I've created a few years ago a toy build tool based on 
capturing calls to open/stat though LD_PRELOAD, and it worked quite well).

     - Completely change the representation of the typing environments 
to maintain a list of "layers" made either of local scopes or namespace 
opens.

   (ii) It allows to write more robust code w.r.t. to future additions 
to namespaces.  With namespaces, library authors won't hesitate to use 
"short" names for their modules and the risk is high that a "open 
namespace" statement hide local modules when the library is extended.

   (iii) It makes dependency analysis more precise (and code easier to 
read).  In the example above, ocamldep knows (with the second semantics) 
that there is no dependency to an external unit X.


-- Alain