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

[Leo White]

> 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?
>

While the second semantics may be easier to implement, it would be
completely counter-intuitive to OCaml programmers.

> [...] 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.
>

Neither of these options seems particularly problematic to me. The
first one might be more in line with checking that some "foo-*.cmi"
exists when the Foo namespace is opened so that typos produce an error
or warning. But if Sys.readdir is a problem then the second option is
perfectly viable.

>   (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.

This is basically just an argument against "open namespace" shadowing
things but, as Yaron has said, OCaml uses shadowing all the time and it
doesn't seem to have caused too many problems. If in doubt use explicit
references instead of opens.

>   (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.

This is no worse than how ocamldep currently handles modules contained
within other modules.