[MLton] upcoming public release

[Matthew Fluet]

> > 2) mlton-compile isn't "resumable".  Consider adding the following to
> >    main.fun:
> ...
> > What this essentially does is dump the world after a compile, and the
> > dumped world is ready to start a new compile.  This would seem to be the
> > best way to accumulate some state between successive compiles.  However,
> > I get:
> >
> > [fluet@lion temp 11]% mlton -dump-world world1 z.sml
> > [fluet@lion temp 12]% mlton @MLton load-world world1.mlton -- z.sml
> > bool has no info property
> >
> > This won't be a trivial task to eliminate this sort of thing.
>
> I agree that eliminating such problems would be hard.  This approach
> would also have negative performance impact by causing the compiler to
> keep around stuff that would otherwise be dead.

It only keeps around state that will be relevant to the next compilation.
True, in the case I have in mind, this state would be cached contents and
elaboration of the Basis and whatever other libraries one wanted.  In that
case, putting the (only) dump/resume point after elaboration would mean
that the cache isn't live down the Original branch (that continues with
the compile) but is live down the Clone branch (which goes back to
commandLine, and hence has elaboration in it's continuation).

> I think it would be simpler to save the world during elaboration,
> since that is where resumption needs to occur.

I still have my reservations about this approach, but I see that it avoids
the resumption issues.