[MLton] upcoming public release

[Stephen Weeks]

> > > * Caching preprocessing of the basis.  Matthew, where are you on this?
> >
> > I gave it a little more thought, and it is probably more difficult than I
> > originally thought. But I'll try to write up what I think might work and
> > where the problems lie.
> 
> I don't think this should happen with this release.

Agreed.

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

I think it would be simpler to save the world during elaboration,
since that is where resumption needs to occur.  This is what I
suggested back in August

	http://www.mlton.org/pipermail/mlton/2004-August/016224.html

There were some other problems with the idea that have since been
solved.  But I think the main idea still makes sense, and is a better
way to go than saving the state after compilation is done.