[MLton-devel] A CM replacement for MLton

[Matthew Fluet]

> Then, we'll leave CM support in
> for a while, but eventually drop it in six months to a year.

If we plan on dropping CM eventually, then we should probably have support
(either in the compiler or as a tool) for converting Portable library
descriptions into .mlb's, as I would imagine turning off a lot of users if
there were no way to use .cm projects.

> and allows renaming of modules without dropping
> down into SML files.

That seems very nice.

> The idea is to have a new kind of file, an .mlb (ML Basis) file, that
> describes a library or program.  An .mlb file contains a "basis
> declaration", defined by the following grammar.
>
> <bdec> ::= <file>.{fun|sig|sml}
>          | <file>.mlb
>          | functor (<fctid> [= <fctid>])*
>          | local <bdec> in <bdec> end
>          | signature (<sigid> [= <sigid>])*
>          | structure (<strid> [= <strid>])*
>          | <bdec> <bdec>
>
> Comments are allowed in (* *).

I find the {functor,signature,structure} repetitions to be a bit confusing
without having any delimiters, although I see that it is quite parsable;
i.e.,

signature S1 S2 = T2 S3 S4 = T4

is supposed to be equivalent to

signature S1 = S1
signature S2 = T2
signature S3 = S3
signature S4 = T4

but the former is virtually unreadable.  Stylistically, I'd only ever
export multiple signatures when none of them required renaming.

> ----------------------------------------
> Relative paths
> ----------------------------------------
> One omission in the above semantics is that pathnames in basis
> declarations can be relative or absolute.  Relative path names (as
> with .cm and .pm) are relative to the directory containing the .mlb
> file.

Sounds right.

> ----------------------------------------
> Sharing and side effects
> ----------------------------------------
> Since .mlb files are elaborated in the empty basis, they only need to
> be elaborated once.  The intended semantics, not covered by the above
> rules is that the results of .mlb elaboration are cached.  Thus any
> effects are not duplicated if the .mlb file is referred to multiple
> times.  This is different from SML files, which are elaborated (and
> duplicated) each time they are referred to.

O.k., although I don't see many cases where one would like SML files to
be elaborated each time they are referred to.

> ----------------------------------------
> Export filters
> ----------------------------------------
>
> The abbreviation for module bindings makes "basis signatures"
> unnecessary.  One simply defines the basis one wants in a very concise
> way.

What do you mean by "basis signatures"?

> ----------------------------------------
> Import filters
> ----------------------------------------
>
> Suppose you only want to import functor F from group1 and functor G
> from group2.  That's easy:
>
> local
>   group1.mlb
> in
>   functor F
> end
> local
>   group2.mlb
> in
>   functor G
> end
>
> CM requires "administrative groups", i.e. extra .cm files, to do
> this, and .pm files require similar machinations.

Unfortunately, it doesn't make it that easy to import all _but_ functor F
from group1.

> ----------------------------------------
> Constructing the Basis Library
> ----------------------------------------

The description of constructing the Basis Libraries sounds right, but
there are two deviations from the way in which we currently treat the
Basis Library: 1) we can't "pre-parse & elaborate" the basis library; 2)
we can't perform the "dead-code" pass.  (There are also minor issues like
the build constants, etc.)

> ----------------------------------------
> Basis suffixes
> ----------------------------------------
> I'm not entirely sure what to do with the basis library suffix that
> handles cleanly exiting the program.  One idea would be to make it
> more intimately tied with the compiler, like we do for the toplevel
> handler.

Treating the suffix like the top-level handler seems appropriate.



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel