[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
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.