[ocaml-platform] Followup to Leo's proposal

[Gabriel Scherer]

One aspect of Leo's proposition that I found lacking is the absence of
a precise framework that could explain the semantics of the proposed
features and study their combination.

In our spec.pdf document, we have a single namespace description
language that is specified rather precisely, and is used to explain
all the semantic phenomenons that are currently scattered in
documentation about "where the compiler looks for compilation units".
We capture this precisely as a "compilation environment": whatever
conventions we adopt for namespace lookup is explained as producing a
namespace description that is taken as the compilation environment in
which the program's semantics is understood. The current command-line
argument -I, for example, is explained in term of the "scan" primitive
(scanning the filesystem for compilation units in a precisely
explained filename-dependent way) and the "merge" primitive (combining
two compilation environments again in a precisely specified way).

(Note that this doesn't mean that the whole namespace description
language has to be exposed to end-users. Some parts of it can be
referred to only internally to explain built-in conventions and
features.)

Concretely, the proposal as it is currently phrased left me wondering:
- how to compose different "search path files" (by concatenation, I
assume; I regret the absence of any conflict handling considerations)
- whether "-open" arguments would still be opened in absence of the
corresponding "open namespace Core" (it looks like "yes", and that
would be a semantics change wrt. the discussed flat-access feature)
- what happens when you write "open namespace Croe", making a typo
- whether each build system would have to implement its own way to
describe which -name option are supposed to be passed to which files;
it would be natural to pass them a description of the expected final
compilation environment (mapping module names to compilation units),
but in presence of -name you need to provide another mapping from
needed-.cmi names to corresponding-.ml names, and each build system
would need to come with its own description language for these "send
all foo/<bar>.ml to foo-<bar>.cmi" (which looks awfully like a
namespace description language)

On a rather orthogonal point, the proposal doesn't explicitly mention
the problem of internal module name conflicts. I assume that the
solution is "-name", meaning that the library authors must make sure
that the -name option they pass (or the source filename) will be
unique among all modules used by their downstream users. As it is an
important responsibility, I think this should be emphasized.

On Tue, Mar 12, 2013 at 12:32 PM, Yaron Minsky <yminsky at gmail.com> 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.
>
> 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.
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform