Frontend/Closure Convert questions...

[Stephen Weeks]

> First, let say that MLton is a pretty cool piece of software. I was able to
> hack at it to get my little toy GC working in it without too much problem at
> all. 

Glad to hear it.  My own opinion is that it's the following that makes
it easy to work with:
	* whole program
	* simply-typed, first-order IL
	* backend generates C
I'd be interested to hear your thoughts.

> I ran a few benchmarks on some very small input programs and was amazed
> to find out that my compiler generated GC was actually faster then the
> native C version.

Cool.  Just to be clear, this is a GC that is "written" in Cps and is
compiled to C with the rest of the program, right?  I'd be very
interested to see sometime the ILs and the C code that gets generated,
and to see how much MLton's optimization is buying you.

> 1. Run ML programs all the way pass closure-convert.fun to get a CPS program
> which I feed back into my IL.
> 
> 2. Hack closure-convert.fun to emit programs in my IL. 
> 
> 3. Write my own Sxml -> IL closure converter.
> 
> I already have a converter from my IL to CPS working. 
> 
>    1. Seems the easiest at first but my IL lacks variant types, and doesn't
>    decompose case statements in the way the current CPS does. My IL looks
>    more like a first order ML source program. 
>    
>    2. May be easy to do, but I'm not so sure it's not easier to just start
>       from scratch. In the longrun I need to treat exception handlers in a
>       different way. 
> 
>    3. Is what I'm leaning toward, it seems like I can just reuse the
>       flow-analysis.sig and it's only a matter of hacking.

I'm afraid I'm going to have to disagree with Suresh.  For exactly the 
same reason that he says 2 is difficult, I think 3 is.

My guess is that 2 isn't as hard as you think.  There's really a fair
amount of complexity in the closure conversion in getting the types
right that makes 3 unattractive.  If you look carefully, the closure
converter is already written for a "direct style" target language.  It
only deals with the "DirectExp" substructure in cps-tree.sig. The Cps
module then translates that to Cps on the fly.  All you have to do is
implement your own translator from DirectExp to whatever IL you have,
which sounds easy to me (not having seen your IL).  You don't even
have to implement the entire DirectExp signature.  A quick grep shows
that all you have to implement is the following:

% grep 'Cexp\.' closure-convert.fun | sed 's/.*Cexp.\([a-zA-Z]*\).*/\1/' | sort | uniq

call
casee
conApp
const
detuple
handlee
layout
lett
primApp
raisee
select
t
toExp
tuple
var

In fact, what I would like to see is for you to use the *same* closure
conversion functor for both MLton's compilation and for your
modification.  You should be able to make minor modifications to the
current closure-convert.{fun,sig} so that it doesn't depend on the Cps
module, and instead only depends on the signature above (a subset of
the current DirectExp signature).  Then, you should be able to
instantiate the functor with Cps.DirectExp in one case and your IL in
the other.

Sound reasonable?