contification transformation

[Stephen Weeks]

> I cleaned this up, so it should be almost as efficient as the current
> transformation.  The actual transformation is almost identical to the
> current version; I just removed some of the cases on contification
> strategy.  The "prep" is a little different.  Essentially, I build the
> following graph: 
> 
> Node = Jump U Fun
> Edge = {(f, g) | A(g) = f} U
>        {(j, g) | A(g) = j}
>        
> and then process nodes of the tree in order of the finishing times of a
> depth first traversal from the roots.  Actually, the graph will be a
> forest assuming that the analysis A is acyclic (which is reasonable for
> the interpretation of A). 
...
> Note also that this transformation would allow b to call a function i and
> still have i contified in b although f and g would be not be contified.  I
> think this pretty much pushes the limit on getting all the functions
> contifiable given the IL constraints. 

I read through this message and pretty much understood it, but I didn't think
about the transformation carefully.  But I'm not sure I need to.

At some point after the paper, I'd like to settle on one contifier.  What's your
opinion on the analysis and transformation that we should leave in MLton? As I
see it, here are the choices.

1. A/ancestor analysis + old transformation
2. A*/parent analysis + new transformation

The advantage of (1) is that it is simpler and is what will be in the paper.
The advantage of (2) is that it allows more to be contified.

Assuming it's not noticeably slower, I lean slightly towards (2), but mostly
just because it's already implemented.