Code expansion due to monomorphization in MLton?

[Franklyn A. Turbak]

Stephen --

Thanks for your incredibly quick and extremely informative 
response to my question! 

There has been a lot of progress during the past year on the
Church CIL ML compiler. We can now compile almost all 
the benchmarks in our (admittedly not so large) benchmark
suite for all combinations of flow analyses and representation
strategies. We now support MLton-style defunctionalization 
as one of our representation strategies (though we don't yet use
the clever hack of having the function pointer be the data tag), 
and we support some other new strategies as well (such as
Steckler-Wand "selective" closure conversion). 

We have two recent papers that might interest you. The first is
our TIC00 paper on program representation size in CIL: 

	http://types.bu.edu/reports/Dim+Wes+Mul+Tur+Wel+Con:TIC-2000-formal-sub.html

The second, "Flow-based function customization in the presence of 
representation pollution", evaluates various function representation
strategies and flow analyses in the CIL compiler. We submitted a version
of this to PLDI, but are revising it to include some more recent results. 
Watch the Church reports page for the revised version:

	http://types.bu.edu/reports/

You mentioned that you periodically check the Church mail archives.
I'm *very* curious how you do this, since the archives are supposed
to only be readable by members of the Church group!  

Thanks again for all your help, and have fun with your MLton hacking!

- lyn -