[ocaml-platform] Followup to Leo's proposal

[Leo White]

> I have no objection to specifying that Core#Common should be connected
> to the Core package within the build system.  But it's important to us
> that namespace manipulations be observable by the programmer by
> reading the code.  If I understand correctly, Leo's proposal involves
> stashing that away in the build system, which undermines that goal.

To be clear, I'm only proposing to stash default opens in the build
system, as oposed to stashing them in the namespace system. I think this
makes sense since it is about controlling the initial naming environment
of a program, just like the search path.

> Another thing which may not be obvious is that one sometimes in the
> same file wants to access just Core.Std in some scopes in the file,
> and Async.Std in other scopes.  

Do any of the values or types opened automatically by Async conflict
with those opened automatically by Core? If there aren't then opening
the default modules globally shouldn't be a problem. 

> Full control of the namespace is
> important, and something we do at multiple scopes within a file.
> Being able to control this only at the file level, and only from
> within the build system, is a poor match for our needs.

You can always control it more explcitly by using Core#Common and
Async#Common directly to ensure that the right values are used in the
right scopes.

> If the proposal lands in the way Leo describes, I would think we would
> write a ppx extension that, for a certain whitelist of namespaces,
> would convert:
>
>    open namespace Core
>
> into
>
>    open namespace Core
>    open Core#Common

That seems reasonable. 

> Given that this is easy enough to do at the ppx level, I find it hard
> to see what difficulties would be raised by integrating this with the
> namespace system.  

I think the awkwardness is more related to how you treat things like:

   Core#Foo

where Foo might be a sub-module of Core#Common.