[MLton] upcoming public release
Tue, 2 Nov 2004 10:45:32 -0500 (EST)
> > * 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. There are a couple of
1) The semantics of MLBs specify a precise order of effects; so, consider
If this is the first occurence of foo.mlb, then the declarations should
look like those from z.sml, then those from foo.mlb, then those from
y.sml. What this means is that one cannot maintain a simple map from
.mlb files to declarations; instead, one needs to maintain a map from
.sml files to declarations, and then walk through the .mlb file to
ensure that the declarations are emitted in the right order. This
isn't hard to accomplish, but it is a delicate point.
2) mlton-compile isn't "resumable". Consider adding the following to
val commandLine' = Process.makeCommandLine commandLine
fun commandLine args =
val st = commandLine' args
if OS.Process.isSuccess st
then (case !Control.dumpWorld of
NONE => st
| SOME file =>
(SMLofNJ.exportFn (file, fn (_, args) =>
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,
[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.