[MLton] upcoming public release

[Matthew Fluet]

> > * 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
different issues:

1) The semantics of MLBs specify a precise order of effects; so, consider
   the following:

   local
     z.sml
     foo.mlb
     y.sml
   in
     ...
   end

   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
   main.fun:

val commandLine' = Process.makeCommandLine commandLine

fun commandLine args =
   let
      val st = commandLine' args
   in
      if OS.Process.isSuccess st
         then (case !Control.dumpWorld of
                  NONE => st
                | SOME file =>
                   (SMLofNJ.exportFn (file, fn (_, args) =>
                                      commandLine args)
                    ; st))
         else st
   end

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.