|grab the continuation at specific point in a program firstname.lastname@example.org (Yakov Z) (2012-06-09)|
|Re: grab the continuation at specific point in a program email@example.com (2012-06-11)|
|From:||firstname.lastname@example.org (Torben Ęgidius Mogensen)|
|Date:||Mon, 11 Jun 2012 13:22:16 +0200|
|Organization:||SunSITE.dk - Supporting Open source|
|Posted-Date:||11 Jun 2012 09:37:13 EDT|
Yakov Z <email@example.com> writes:
> AFAIU, to grab the continuation at specific point in a program I still
> have to do CPS conversion of the whole program (because CPS is global)
> I then end up with a lot of uninteresting continuations (like for
> constants and variables etc.)
> If I want to get rid of those and leave only one "at that point"
> continuation (with everything on which it depends upward the call
> path) I need to perform another transformation. Do you know if
> approaches exist to do the above in one run?
You don't need CPS conversion if you can get access to the computation
state -- specifically the function call stack. The continuation is in
that case "just" a copy of the call stack. This makes it rather costly
to grab or call a continuation, but there is next to no cost for
programs not using call/cc. If the call "stack" is represented by a
linked list, grabbing and using continuations is cheaper, but it means
you have to GC the call frames instead of unstacking them, which may or
may not be more expensive. CPS transformation gives essentially the
same effect, as closures are typically heap allocated.
In all cases, continuations are a bit questionable if you have mutable
variables: When a continuation is called, do you want to return these to
the state they had at the time the continuation was grabbed, or do they
keep the values they have at the time of the call? Is there a
difference between register-allocated variables, stack-alloctaed
variables and heap-allocated variables? The answers to these questions
may limit the choices of how to implement continuations.
Return to the
Search the comp.compilers archives again.