flatter closure conversion

[Stephen Weeks]

> Basically you are delaying the construction of closures.   This  might  be  a
> win,  but  it  might be a loss.  If you can avoid building the closure at all
> (lets say because of some inlining) then you win.  On  the  other  hand,  you
> might  end  up  building  the  closure  many  times,  in which case you lose.

If this happens, I agree. 

> Are  you convinced that it really is going to be a win over all?  I don't see
> why.  (Mind you, I'm sure that there are programs where it would be.)

What I believe to be the mitigating factor in this situation is the
flattener, and the fact that even when the inner closure appears to be
constructed in the output of the closure converter, after subsequent
optimization, the closure variables will just be passed along.  This
is unfortunately not happening right now because the current flattener
only goes two levels deep.  I also think there will be a space *win*
in practice because of avoiding redundancy in closures.  I also think
there will be a win in compile time, because the output of the closure
converter will have much smaller types, and hence subsequent cps
optimization (esp constant propagation, useless, and flattening) will
be better.

If you look at the cps output for, say, the self compile, you will see 
lots of deeply nested types for closure records, many of which appear
to contain redundant components.