[ocaml-platform] Followup to Leo's proposal

[Yaron Minsky]

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.

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

The fact that one should write:

open Core.Std
open Async.Std

in a specific order does not strike me as a particular problem, and
even if it were, the solution I think would not be to stuff it into
the build system, but to build a single namespace that opened both
Core and Async.

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

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 understand that it feels mildly unsanitary
because on the implementation end the two things are quite different,
but from a user point of view, I think it's very much the right thing.

y


On Tue, Mar 12, 2013 at 6:57 AM, Leo White <lpw25 at cam.ac.uk> wrote:
>> Leo's model allows the build system to precisely set the order of default
>> opens, and tools such as ocamlfind could support this just as they do
>> include and link directives at the moment.  I know JS doesn't use
>> ocamlfind, but the moral equivalent could inject the command-line
>> directives very easily.
>
> To expand on what Anil said, under my proposed system the idea is to push the
> problem of providing "pervasive" modules into the build or package system.
>
> For example, I would expect Core to provide some kind of package description
> for OCamlFind or similar tool including something like (using made up
> syntax):
>
>     path := ./core.mlpath
>     open := Core#Common
>
> where "core.mlpath" is a search path description file.
>
> Then Async would include a description including something like:
>
>     path := ./async.mlpath
>     path-depends := core
>     open := Async#Common
>     open-depends := core
>
> where "async.mlpath" is a search path description file that includes:
>
>     Core#Original#*: Core#*
>     Core#Gc: Async#Gc
>     Core#Condition: Async#Condition
>
> where "Gc" and "Condition" are the components of Core that Async
> re-implements.
>
> This would mean that commands equivalent to any of the following would all
> produce the correct default environment for using Async:
>
>     ocamlc -package async
>     ocamlc -package async -package core
>     ocamlc -package core -package async
>
> I think this is preferable to requiring all users of Async to start their
> files with:
>
>     open Core.Std
>     open Async.Std
>
> which is not something that a user might naturally assume was required.