[MLton-devel] A CM replacement for MLton

[Stephen Weeks]

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

An excellent suggestion.  Even better would be a piece of SML/NJ code,
somewhat like cmcat, but working with recent versions of SML/NJ, that
SML/NJ users can use to convert their CM files into mlb files.

> as I would imagine turning off a lot of users if
> there were no way to use .cm projects.

I wonder how people use MLton on big projects.  Do they use it like we
do, with a separate tool to take the cm (or pm) file and produce a
file list, or do they actually try to use the same cm files for both?

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

We could enforce this with the grammar.

<bdec> ::= ...
         | signature <sigid>*
         | signature (<sigid> = <sigid>)*
 
Although I would never write the unreadable version like you did.  I
would write it like

signature S1 
          S2 = T2
          S3 
          S4 = T4

or maybe

signature 
   S1 
   S2 = T2
   S3 
   S4 = T4

That looks pretty readable to me, and the mixing is concise.

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

Agreed.  I chose that design because I didn't want some
hard-to-understand form of caching, since the file might be elaborated
in different bases at different points.  Another simple rule would be
to disallow multiple references to a file.  But that doesn't seem any
simpler and loses a little bit of power.

> What do you mean by "basis signatures"?

I considered some designs where the bdec language was much more
powerful, and included ways (other than the filesystem) to name a
basis.  At that point is was natural to consider "basis signatures"
that could be used to constrain a basis, in a similar way that
signatures constrain a structure.  E.g.

<bsig> ::= sig <bspec> end
<bspec> ::= basis <bid>: <bspec>
          | functor <fctid>
          | signature <sigid>
          | structure <strid>

This is the easiest approach, with just namespace management and no
additional type theory.

In any case, I abandoned these designs as too complex and to verbose.

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

I'm not sure it's worth an extra construct to subtract names from a
basis, but it might be.  The only case where I can think you would
want to do this is where you have another definition of functor F that
you want, say from group2, in which case it is easy to get the effect
you want.

group1.mlb
local
  group2.mlb
in
  functor F
end

Can you think of other cases?

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

I don't understand (1).  It seems to me that because mlb files are
elaborated in an empty basis, we can pre-elaborate any that we get our
hands on.  But maybe machines are getting fast enough that the
pre-elaboration isn't worth it.  I can see a few advantages to
distributing the basis library sources with the MLton binary packages.
First off, people will read them.  That will help them understand the
semantics, will help find bugs, and will allow them to make fixes.
Second, it should make our binary packages smaller.  The gzipped basis
libary sources are <200k, while the gzipped world.mlton is >3M.

As to dead-code, you're right that our current pass won't work.  My
thinking is that we will have a more general pass that works the same
on both user code and basis library code (which would be good) -- some
of the files in the project are marked as required and any file that
isn't needed to elaborate some required file is eliminated (even if it
may have side effects).  As to marking files, we can either go with
some simple implicit rule like the last file in the project is
required, or we could go with explicit keywords in the mlb files.  We
could also have a switch in MLton to control whether this form of
aggressive dead code elimination is even run.

BTW, I am not attached to the term "ML basis file" or to the .mlb
suffix, although they seem reasonable.



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