[MLton] speeding up type checking by caching

[Daniel C. Wang]

Stephen Weeks wrote:
{stuff deleted}
> 
> Interesting idea.  But I don't think the difficulty with caching is in
> dumping the state -- it's in deciding when it is correct to resume
> from the dumped state.  Whether the state is dumped to a file or a
> forked process doesn't make that any easier or harder.  I don't
> understand what "state synchronization issues" you mean.  And I think
> the permission issue is avoided by writing the cache file(s) to
> ~/.mlton/cache/ (plus this allows different people to cache different
> things).  One benefit of doing this could be speed, but I want to see
> how fast we can go with the disk dump before going this route.

What happens in the case the ~/ is on a shared FS and I'm running multiple 
instances of MLton on different machines? This may not be a "common case", 
but I'd say its not exactly uncommon. In any case, my state synchronization 
issue assumed that there was a global pre-elaborated basis for the enitre 
system, but if each user is caching all their state on disk and state is 
being duplicated rather than shared most of what I'm worried about isn't an 
issue.