[MLton] caching elaboration

[Stephen Weeks]

> I'll note that the proposal seems to point towards a scheme where
> elaboration prompts lexing/parsing. 

I don't see why (but you have a much better understanding of this
stuff right now).  The architecture I was thinking of was to have a
separate module that would handle "assumptions".  Then, any piece of
code that made some assumption about the environment would record that
assumption with the module.  For example,
{,MLB}FrontEnd.lexAndParseFile would record an assumption when they
open a file.  And main.fun would record assumptions about the current
working directory and command line arguments.

Then, the caching code would use the assumptions module, which would
provide appropriate functions for writing the assumptions out to a
file and checking the assumptions are true.

I think this is minimally invasive and doesn't require much code
reorganization.  So, I don't see that it points either way for whether
elaboration prompts lexing/parsing.

> That seems fine (and it will probably make the lexer/parser for MLBs
> simpler), but it will change the behavior of the compiler.

It seems fine to me too.

> In particular, it will no longer be the case that all elaboration
> type-errors will occur after all syntax errors.

Hmmm.  This definitely changed at some point since the last release.
When processing a CM file, it used to be the case that each file was
parsed and then elaborated.  So, if there was a type error in one
file, one would *not* see parse error in a later file.  I just tested
this with 20040227 to confirm.  I also just tested with the CVS head
and see that I now get the parse error in the later file and do not
see the type error in the earlier file.

I have a slight preference toward reporting all errors in one file
together, before reporting any errors in a later file (not least
because it is somewhat arbitrary as to how certain errors are
classified), so I think it would be nice to go back to the old
behavior for CM files, and to treat MLBs similarly.