[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Abstracting continuations
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.