[MLton] mlb support

[Matthew Fluet]

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

It controls both _build_const and _const.

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

It is easy enough to go with "allowRebindEquals"; it's only being used in
a few places.

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

I picked defaults that were consistent with what we currently
allow/intend.  (Technically, we currently allow _overload and _prim in
user code; but, we certainly don't mean for them to be used outside the
basis.)

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

Good.

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

That's a bit verbose for my tastes.

> 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 is a little bit better.  Although, I would choose $(SML_LIB) over
$(LIB).  I've set things up so that $(VAR) is interpreted by
OS.Process.getEnv, and LIB seems like a likely candidate to already be in
use.

> One thing I'm not sure I like is the redundant mlb file name.

I don't have a problem with it.  I think conventions like lib.mlb and
sources.mlb obscure things.

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

Actually, it's neither of these things.  Both the MLB parser and the MLB
elaborator want to cache .mlb files.  I just haven't set things up so that
you can run the parser and the elaborator with a cache and get an updated
cache back at the end.  Also there is the minor issue of identifying .mlb
files by inode.

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

YMMV.  On my home machine, an SML/NJ-exported version of MLton takes about
6minutes to elaborate the basis-library.  So, I've been just as happy
without the basis being processed at export, because I get a compiler
faster, which is sufficient for little tests on .mlbs that don't pull in
the basis.  When I want to do a serious test, I recompile with MLton.

But, I think that threading the cache's through should be easy enough.