[MLton] mlnlffigen is awesome (was: bootstrap problem)

[Matthew Fluet]

> > If mlnlffigen is included with the mlton.tgz why are smlnj and ckit
> > not?
> 
> No good reason.  We plan to include both smlnj and ckit in the package
> starting with the upcoming release.

I have added the SML/NJ Library and the CKit Library to the collection of 
libraries distributed with MLton.

The libraries are distributed via .tgz files for the libraries (taken from 
SML/NJ 110.55) and .patch files that adapt the libraries to MLton.

There is one relatively minor issue.  Both the SML/NJ HTML Library and the
CKit Library make use of MLLex lexers and MLYacc parsers.  Because cm2mlb
produces a very "tight" dependency tree, the minor differences between
SML/NJ's and MLton's mllex and mlyacc tools are relevant. Therefore, I
have included (MLton mllex and mlyacc) derived files in the patch to
ensure compatibility.

A second point: I have not modified the mlb-path-map in the way described
by http://www.mlton.org/SMLNJLibrary and http://www.mlton.org/CKitLibrary.
I'm a bit undecided on how best to use MLB path variables.

I find CM's whole notion of anchored paths a bit confusing.  I don't find
the "When to use anchor environments" scenario in the CM manual to be all
that compelling.  Hence, it really appears to me that anchors are only
about getting around the bootstrap problem.  In which case, it seems to be
a whole lot of complexity to expose to the user.

So, I don't want to fall into the trap of giving MLB path variables to 
everything.  Furthermore, that is a sure means of leading to conflict down 
the line.  For example, SML/NJ Library has an HTML sub-library, which 
SML/NJ provides via the anchored path $html-lib/html-lib.cm (or the 
shortened form $/html-lib.cm); but that excludes anyone else from 
developing something called html-lib.  So, I don't want to start adding 
$(HTML_LIB), etc.  I could see adding $(SMLNJ_LIB) and $(CKIT_LIB) as 
described on the web-pages above, though I don't know if it is strictly 
necessary.  One could likewise start adding $(CML), $(MLNLFFI_LIB), and 
$(MLYACC_LIB).  All of these seem o.k., at least in terms of it being 
unlikely that there will be name clashes down the line.

Anyways, I'm happy enough with just using $(SML_LIB) and nothing else.  If 
anyone wants shorter names, then they can modify their 
.mlton/mlb-path-map.  If they want to later distribute their code, then 
they'll need to clean it up to be compatible.

Alternatively, we could provide a -mlb-path-map <file> flag to the
compiler (which would augment (and take precedence over)
/usr/lib/mlton/mlb-path-map and .mlton/mlb-path-map), in which case
someone could distribute their specialized path map along with their code,
and simply use the Makefile to ensure compatibility.