[MLton] speeding up type checking by caching

[Daniel C. Wang]

Might, I suggest a hack that avoids the hassle of actually dumping state to 
disk. Have MLTon have a --server option that on first invocation elaborates 
a .mlb then forks a child process to do the actual compilation. The parent 
hangs around as a background process.

Future invocations with --client look for the already running instance and 
cause it to fork and elaborate as needed reporting errors to the client 
program. This also might be a useful hack for dealing with cross compilation 
by running a cross compiler on a remote machine while developing "locally" 
on the target machine with a very simple C/Perl based client wrapper.

Imagine you could hack up something similar in spirit to distcc for MLton
   http://distcc.samba.org/

If you never actually write state to disk you can avoid some of the state 
synchronization issues not to mention the issue of permissions associated 
with a disk cache when there are multiple users.


Stephen Weeks wrote:
> The more I think about it, the more I like the idea of speeding up
> type checking by transparently caching the result of preprocessing
> part of the program.  The semantics is simple -- to the user, it
> should be as if the whole program is type checked every time they call
> MLton.  But internally, we are free to save worlds that result from
> type checking part of the program, and to restart with those worlds if
> we can prove that it is equivalent to type checking the whole program.