[MLton] mlb support

[Stephen Weeks]

> I've got mlbs working to the point where pretty much everything except for
> the def-use controls is working.  Currently, the annotation language looks
> like:
> 
> ann := allowConstant {true|false}   defaults to false
>      | allowExport {true|false}     defaults to true
>      | allowImport {true|false}     defaults to true
>      | allowOverload {true|false}   defaults to false
>      | allowPrim {true|false}       defaults to false
>      | deadCode {true|false}        defaults to false
>      | rebindEquals {true|false}    defaults to false
>      | sequenceUnit {true|false}    defaults to !Control.sequenceUnit
>      | warnMatch {true|false}       defaults to
>                                     (!Control.warnNonExhaustive
>                                      orelse !Control.warnRedundant)
> 
> The defaults are reset for each .mlb file.

Looks good.  

Does allowConstant control _build_const, _const, or both?  I guess
both, and there's no reason to distinguish.

I wonder if "rebindEquals" should be called "allowRebindEquals" for
consistency.  It is a bit verbose, though.

We could make false the default for allowExport and allowImport.  That
way people have to be explicit when they want to step outside the
language.  Although this would conflict with what we currently do, and
maybe the leading "_" is enough.

> Is there a reason that warnMatch is split into the two controls?

No good reason.  I did it simply because it was possible to
distinguish the two kinds of warnings.

> I haven't gotten rid of the !Control.warnNonExhaustive or
> !Control.warnRedundant predicates in defunctorize.fun.

I have no objection to getting rid of the distinction between the two
controls, and makign the default value of the warnMatch annotation be
the value of !Control.warnMatch (which is set on the command line).

> One question is where to make SML_BASIS actually point.  Recall that the
> directory structure for the basis-library looks like:
> 
> basis-library/libs/build
>                   /basis-2002/bind
>                   /basis-1997/bind
>                   /basis-none/bind
> 
> That was fine for before, but I don't want to write:
>   $(SML_BASIS)/libs/basis-2002/basis-2002.mlb
> 
> I'd rather write:
>   $(SML_BASIS)/basis.mlb
>   $(SML_BASIS)/basis-2002.mlb
>   $(SML_BASIS)/basis-1997.mlb
>   $(SML_BASIS)/basis-none.mlb
> 
> so I'm thinking of pointing SML_BASIS to basis-library/libs.

I'm wondering what's the plan for all the other libraries (like CML,
OpenGL, ...) with the packaged version of MLton.  If libraries live in
/usr/lib/mlton/sml/, which is where basis-library/ lives, why not use
a single variable for both the basis library and for other libraries?
Then, we can move the basis mlbs to the top of the basis-library
directory, and reference them as

	$(LIB)/basis-library/basis.mlb
	$(LIB)/basis-library/basis-2002.mlb
	...

Or, we could even change the name "basis-library" to "basis", since
the library part is redundant.

	$(LIB)/basis/basis.mlb
	$(LIB)/basis/basis-2002.mlb
	...

That doesn't look too bad to me.  And other libraries would be
accessed like:

	$(LIB)/cml/cml.mlb
	$(LIB)/opengl/opengl.mlb

One thing I'm not sure I like is the redundant mlb file name.  We
could adopt some convention like:

	$(LIB)/cml/lib.mlb
	$(LIB)/opengl/lib.mlb

Or, parroting the CM convention:

	$(LIB)/cml/sources.mlb
	$(LIB)/opengl/sources.mlb

> As a consequence of this rearrangement, the SML/NJ compiled version of
> MLton doesn't pull in the Basis Library.  Means that things will be a
> little slower, but they were going to be anyways, because expanding a
> single z.sml file to
>   local $(SML_BASIS)/basis-2002.mlb in z.sml end
> meant sucking in the basis at compile time.

I'm not completely clear on why you can't still cache the elaboration
of the basis and then check for its use.  Is it the desire not to
hardwire a constant or two?  Or is it the desire to get the
annotations (like sequenceUnit) that aren't covered by the basis mlbs?
Since the SML/NJ-exported version of MLton is just a hack for testing,
it's worth it to me to compromise a little to get back some speed.
IIRC, we're talking 10-20s per compile.