[MLton] speeding up type checking by caching
Daniel C. Wang
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.