[MLton] mlb support

[Matthew Fluet]

> > Also, I'm not keen on the showX <file> annotations; seems weird to
> > produce these files just based on the annotations.
>
> I agree it's strange to cause side effects with the annotations. But,
> it's not a showstopper to me.  Also, we're already causing elaboration
> side effects with the other annotations (allowConst, rebindEquals).

Yes, but changing the elaboration doesn't require Makefile hackery to
clean up after myself.  Also, there is the big complicated question of
where those files are written, since within an .mlb, relative file names
are supposed to be relative to the location of the .mlb.

I can't imagine leaving showBasis in a .mlb library that I ship out the
door.  Or even in something that I'm using on a regular basis.  So, if I
need to go in and edit the .mlb files to print out a basis (and go back
and edit them to turn it off), then I'm doing no more work to write up a
quick little .mlb file that corresponds to exactly the basis I want to
print out and running with -show-basis <file> on the new .mlb.

And, I suspect that Henry's use is the common case. So, if I want to see
the basis of some library, just compile the appropriate .mlb.

> -show-basis
> 	we could only allow it on the command line or we could have it
> 	as side-effecting annotation.  Neither of those is problematic
> 	from an implementation perspective.

My opinion on this should be clear by now.

> ann := allowConst {false|true}
>      | rebindEquals {false|true}
>      | keepDefs {false|true}
>      | sequenceUnit {false|true}
>      | warnMatch {false|true}

I'm on board with this (possibly minus keepDefs), so that at least gives
me a next step.  And I agree that your proposal can be implemented without
major additions to the elaborator infrastrure, so it is probably a good
first attempt.

One remaining question is whether or not .mlb files should be elaborated
in the "empty" annotation environment.  Doing so is certainly simpler, as
there is no conflict that needs to be resolved for the same .mlb file
being included under different annotations.  On the downside, it makes
dealing with fine grained projects a little more difficult.  For example,
note that the mlton sources have a .cm file in each directory.  We would
probably switch over to a .mlb file in each directory.  Now, just
annotating the top mlton.mlb with warnMatch true isn't enough to ensure
that each sub .mlb will be compiled with warnMatch true.  Likewise, I'd
like to see the Basis Library handled with more than a single .mlb file;
that might not be so bad, as allowConst need only be enabled for
misc/primitive.sml and posix/primitive.sml.