[ocaml-platform] Followup to Leo's proposal

[Yaron Minsky]

On Tue, Mar 12, 2013 at 5:26 PM, Leo White <lpw25 at cam.ac.uk> wrote:
>> 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.

There are conflicts.  Core exposes blocking operations, and Async.Std
hides them.

But shadowing and conflicts are a distraction.  The main issue is that
we want namespaces to be explicit in the source, and possibly
explicitly different in different sub-bits of the same file.  Having
namespace opening be a special-case thing that only happens on the
file level and that is hidden from the source3 just seems like an
unfortunate special-casing of a namespace manipulation tool (like let
and open) that should be available generally.

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

Just to be clear: we will not use auto-opens driven from the build
system.  They undermine our ability to understand the code from
reading the source.  So, yeah, we can open Async#Common explicitly,
but that means lots of files will start with

   open namespace Core
   open Core#Common

and others will start with

   open namespace Core
   open Core#Common
   open namespace Async
   open Async#Common

and yet others will start with

   open namespace Core
   open Core#Common
   open namespace Async
   open Async#Common
   open namespace My_framework_namespace
   open My_framework_namespace#Common

I'd rather these read like this:

   open namespace Core
   open namespace Async
   open namespace My_framework_namespace

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

It's reasonable, but fairly depressing.  I feel like we're proposing a
new namespace system that from the get-go doesn't satisfy the needs of
some of the major users, and needs to be hacked around to get it
there.

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

Can you elaborate a bit?  Why is this case problematic?  I can kind of
see why this is weird, but other than making an explicit requirement
of having an ordered semantics (which to me seems like the right
answer anyway, since it's more in tune with how OCaml's other
namespace manipulation operators work), it seems fairly
straight-ahead.  But I'm probably missing something important.

y