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

[Alain Frisch]

On 03/19/2013 11:11 AM, Leo White wrote:
> 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.

Sys.readdir is not currently a problem, but it might prevent alternative 
approaches to discovering dependencies.

While perfectly viable, the second option will significantly complexify 
the definition of the typing environment.  We should carefully evaluate 
the impact on the size of .cmt files and on compilation time (in 
-bin-annot mode, in particular).

If I had to choose, I'd probably use the first approach (Sys.readdir).

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

People have carefully avoided to use common name for modules in 
libraries, in order to avoid name clashes.  With namespaces, this can 
changes.  And with the notion of namespaces being more open than module, 
it's even harder to be sure that opening a namespace will never shadow a 
local module. The same would actually apply to other units in the 
current project, not only local modules; so I'd actually propose to look 
for module in the local namespace -- whatever this means -- first.

Concretely, if Core adds a new module Foo, this will break all projects 
using a local Foo module and which "open namespace Core".  A possible 
solution would be that Core ships many .mlpath files corresponding to 
module exposed in older releases, so that there is a way to ensure that 
"open namespace Core" does not bring more modules in scope than before.


Alain