[MLton] speeding up type checking by caching

Daniel C. Wang danwang@CS.Princeton.EDU
Fri, 13 Aug 2004 22:46:39 -0400

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

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.