[MLton] mlb support

[Matthew Fluet]

> With regards to caching the .mlb files for the basis and the like, I would
> say that it is probably a bit scary too not re-lookup the inode number and
> device on each run.  I'm thinking that a copy (to another machine for
> instance) will change them.

Certainly copying the basis on installation will change the inode number
of files.  That would suggest that we have a post-install operation to
read in .mlbs and output a world with them parsed/elaborated.

Of course, there is a whole tricky mess of how to decide that a previously
loaded .mlb corresponds to the file-name now under consideration.  If you
can't trust the inode from run to run, then you need to look things up by
(absolute?) (real?) path name.  But that begs the question of what to do
if $(VAR) changes from one run to the next?  And what if I change a .sml
file referenced by a .mlb?  When, and how do I find out that I need to
rebuild the cache?  Honestly, it just seems like a slipperly slope to CM's
(confusing) notion of stable libraries.

> Re the redundant names, it does look a bit bad to me.  What about (tounge
> only slightly in cheek) t.mlb as the name of the file?  (Or maybe m.mlb.)

I think you spend the majority of your time looking at .sml files (where
Foo.t is a win over Foo.foo) and a minority of your time looking at .mlb
files.  Again, it's a slippery slope from shortening names, to implicitly
expanding
 $(SML_BASIS)/basis
to
 $(SML_BASIS)/basis/{basis.mlb,sources.mlb,lib.mlb,t.mlb,m.mlb}
and CM's (confusing) notion of anchors.