Re: Demystifying Continuations

[Ken Dickey <address@hidden>]

Dave,

Good description.  Three notes w.r.t. Scheme continuations (via call/cc).
  [1] Continuations, when invoked, interact with the dynamic  environment 
because dynamic wind is used.  (dynamic-wind <before> <thunk> <after>)
  [2] Side effects are preserved.
  [3] The usual semantics are correct w.r.t. stack based implementations 
(see note below).


[1] means that within a dynamic wind, when a continuation is captured which 
"escapes" the context of the dynamic wind, the <after> thunk is invoked.  
If/when the context is reentered, the <before> thunk is executed.  This is 
true no matter how many times the continuation is invoked.  

A simple example is the "machine tool invariant".  I.e. <before> starts a 
drill press, <after> stops a drill press, <thunk> performs some operations.  
In writing error code which deals with processing steps, one may "escape" to 
the meta/control level to deal with some situation, then "resume", at which 
point the machine tool is restarted.

[2] Side effects in a dynamic language are only a problem with "immediate" 
values.  I.e. if you set a local variable from 3 to 5 at one point and then 
"re-execute the stack", the code (in Scheme) will see 5, not 3, the second 
time.  This means that some values have to be boxed and screws some compiler 
optimizations.  [So in an optimized Scheme implementation functional 
programming really is cheaper than imperative programming!].

[3] Control does NOT jump from one stack to another in some weird way (i.e. 
your intuitions are correct--one does not, e.g., throw error continuations 
among different stacks).


Perhaps the clearest exposition in term of implementation trade-offs is the 
paper: "Implementation strategies for continuations" by Will Clinger, Anne 
Hartheimer, Eric Ost.  PDF available at:
	<href=http://lambda.weblogs.com/discuss/msgReader$2959>

Will's email and phone are on his home page 
<href=http://www.ccs.neu.edu/home/will/> .  He did the lions share of the 
core MacScheme (bytecode & native code) implementation and is very clear on 
semantics. I'm sure he would be happy to answer operational questions.

Cheers,
-KenD