Tue Oct 25 12:19:55 EDT 2011

2 levels: dataflow and control flow

I wanted to make the "makeVar" operation generic so we can have two
representations: one for Env and one for Expr.  Though it seems that I
have to bind Code representation to Env directly, so it might make
more sense to just get rid of Env and go for Expr directly.

It looks like 2 changes are needed:

 - Replace Env with Expr, working with Let constructors.
 - Make the variable naming state more explicit.

Probably easiest to do the latter first.  Indeed was straightforward,
now the next one.

Does it need to be a zipper?  If I recall the MetaOCaml code I'm
trying to recreate did not have a zipper structure.  Why is that?  It
did some CPS magic to make sure that the eventual return value of the
expression had the let form, but the current "hole" was passed the
reference.  How did that work?

This is what needs to be changed:

makeVar :: TypeOf (Code t) => (Code t) -> MCode r (Code t)
makeVar term@(Code sterm) = SC c where  
  c (State bs n) k = k (State bs' $ n+1) (Code $ Ref $ var) where
    var = Var typ v 0
    v = regPrefix ++ (show $ n)
    bs' = (Bind var sterm) : bs
    typ = typeOf term

Let's see.  The real point is the following: the stuff above works
well descending into an expression.  The context is indeed represented
as a zipper.  What needs to be done is to find out when we get to the
inner node.  At that point we need to provide a return value for the
enclosing contuation, and at that point we can invert the zipper.

These inner points are function calls, or maybe a "return" which is a
tail call to the toplevel continuation.

So the idea is to simply keep the makeVar code above, but extend it
with a zipper.

But first, find out if the original paper[1] uses a zipper.

No, it does not.  But it manipulates the continuations in a way that
looks like delimited continuations, and a dcont has a call stack that
takes the form of a zipper data structure.

[1] http://www.cs.rice.edu/~taha/publications/conference/pepm06.ps