[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Abstracting continuations



At 10:11 AM -0400 8/16/03, Felix Klock's ll1 list proxy wrote:
>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.

Nope. It'd have to resume after the end of the statement or 
expression, depending on how you wanted to express it. (I'd go for 
the next statement, as your following example demonstrates the 
problem wiht resuming expressions)

>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?

Were I to do it, I'd have it call finally_do(), though that restricts 
somewhat the things that you can do with it. (OTOH, I'm more an 
implementation guy than anything else, so the fact that the ultimate 
form is awkward or limiting doesn't bother me, since it's just a 
matter of transforming a nice version of the source to the awkward 
form)

>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)

No, I'm talking full continuations here. setjmp is a nasty, mutant, 
evil, twisted abomination posing as a useful function. (Though I 
suppose I might be being a bit kind :)
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk