Re: Abstracting continuations

["Felix Klock's ll1 list proxy" <address@hidden>]

On Friday, August 15, 2003, at 08:57  PM, Dan Sugalski wrote:

> (I see this one's been missed in all the fun...)
>
> At 2:20 PM -0400 8/13/03, Michael St . Hippolyte wrote:
>> I am trying to improve my understanding of continuations
>> from the point of view of programming language design
>> rather than implementation, i.e. what sort of syntax is
>> necessary to give programmers the power to express
>> continuations, regardless of how it's implemented.
>
> In their simplest form, continuations don't require any syntactic 
> support. A simple:
>
>    foo = takecontinuation();
>
> to make foo a continuation object, and:
>
>    invoke(foo);
>
> to use the continuation are sufficient.

Does the continuation you're capturing above include the assignment to 
foo?  I'm guessing it doesn't, since your invoke(foo) command is not 
also taking an argument that is the value to be returned.

So, I'm guessing that this version of continuations have a very 
imperative flavor, where they aren't capturing the entire continuation 
at the point where takecontinuation() is called, but rather only the 
continuation AFTER the statement holding the takecontinuation() 
expression, right?   So, what would your formulation do here:

    if ( foo = fakecontinuation(), 1 ) {
       then_do();
    } else {
       else_do();
    }
    finally_do();
    invoke(foo);

Would the invoke here cause finally_do to be called next?  Or then_do?

Tangentially, I haven't worked too much in C, so I don't know whether 
you're describing the equivalent of setjmp() and longjmp(), but the 
descriptions I've heard of them sound very much like what you're 
describing here...  (perhaps the distinction is that they only capture 
the runtime stack, so they would not capture the remaining statements 
to be executed only the functions that we're returning to...?  Perhaps 
we should describe the various granularities [[expression, statement, 
call-stack]] that are available for capturing continuations)

-Felix

p.s. as a final note to Michael St. Hippolyte, the whole point of 
describing CALL/CC in the Scheme report [[instead of CATCH]] is that it 
adds no new syntax; CALL/CC is just a procedure, like APPLY or CAR; its 
implementation may require exposing details of the runtime 
implementation, but its syntax and invocation semantics are the same as 
any other procedure.  They are not special forms like LET or IF.