[ocaml-platform] Followup to Leo's proposal

[Leo White]

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