upcoming release

[Stephen Weeks]

> This is close to being fixed.  I've run through all of the regressions
> with a G0 (and also Anoq's problem case) with the new version, and they
> work.  Having not kept up with all of the runtime, MLton structure, and
> script changes, I've not been very successful at bootstraping.  I'm not
> going to get around to it this afternoon, but if anyone wants to grab a
> copy of the new code and try out self-compiles and benchmarks, I put it at
> http://www.cs.cornell.edu/People/fluet/MLton/known-case.fun

Great!  I tried my usual three-round self compile and it worked fine.
I am now running benchmarks.

> Two side notes on bootstraping:
>  -- I seem to remember being able to bootstrap from a G0 to a G1 in just
> over an hour on my 800Mhz PIII.  But, I tried it last night and it was
> over 90 minutes just in pre-codegen.

Hmmm.  A few weeks ago, something got introduced to make the
executable grow from about 7.5M to 9.5M.  Self compile times also went
up (because of the larger ILs) from about 250s to 350s on my machine.
I never did track the problem down.  I guess that could be the cause.

>  -- While the mlton-stubs is nice, I was really suprised when I got a
> working executable out of a self-compile using mlton-stubs.cm, because
> the stubs don't define a useful MLton.World.save. The compiler also
> depends upon SMLofNJ structure, which isn't in the mlton-stubs, so we end
> up using the SMLofNJ in the basis-library of the compiling compiler, the
> closure of which includes the MLton structure and working
> MLton.World.saves.  Just thought it worth pointing out that mlton-stubs
> does not turn the mlton sources into strict Standard ML; on the other
> hand, providing stubs for the SMLofNJ structure would probably make
> bootstraping from an old compiler even more difficult.

Good point.  That was an amazing bit of luck that I didn't even
notice.  If we ever need to work around it, we can bootstrap using a
version of MLton that doesn't require
MLton.World.save/SMLofNJ.exportFn by using a version that processes
the basis library for each compile.  I had such a version a week or
two ago, but it added a few seconds per compile, so I ditched it.  But
for bootstrapping it would work fine.