[MLton] upcoming public release
Tue, 2 Nov 2004 13:45:01 -0800
> > > * 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.
> 2) mlton-compile isn't "resumable". Consider adding the following to
> 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
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.