Scope rules for CPS and other questions...

[Stephen Weeks]

> Ahhh, I've been missreading the IR okay, so it is CPS. It's just that the
> return continuation isn't an explicit parameter but something that's
> implicitly maintained. 

Exactly.  There's no need to "pass" it around to all of the local
functions within a toplevel function, since it never changes, and
there is no need to build up a dynamic data structure (continuation)
to represent the local control flow in a function since it is known at 
compile time.

> I'll need an explicit encoding of the closure for the return continuation
> for the work I'm doing, so the garbage collector can get access to variables
> that are on the current stack frame.

Whoops.  You're right.  backend/live.{fun,sig} is the pass that
computes exactly this information (in kind of a cool way) to be passed
along to the GC.

> I need it translated into a version with a explicit continuation parameter
> and explicit continuation values.
> 
> let
>  datatype cont = K1 | K2 of int
>  fun f(k:cont,x:int) = apply (k,x)
>  and apply (K1,x) = f(K2 x,2)
>      apply (K2 x,y) = halt(x,y)
> in f(K1,1)
> end

The problem with this in MLton is that this will cause all stack
frames to get allocated on the heap.  MLton was designed so that the
call stack really is stack allocated.  I suspect that your
transformation will kill performance.

I'm wondering if there isn't some simple extension of Cps that you
could do that includes the information produced by Live as annotations
in the tree and that would let you preserve the stack allocation of
the call stack.