Re: Abstracting continuations

[Dan Sugalski <address@hidden>]

At 2:21 PM -0400 8/18/03, Michael St. Hippolyte wrote:
>I think I need to rephrase my question... I understand how to define 
>a continuation by taking a snapshot of the relevant program state at 
>a particular point in the running of the program.  What I'm curious 
>about is whether there are any languages that let you define a 
>continuation without actually having to run the program to that 
>point first.

I think that, in general, you're out of luck here. (Well, OK, there's 
always INTERCAL's COME-FROM, but besides that...) For there to be 
call state, you sorta have to know what path you'd take to get to 
that spot, and for any non-trivial program that's, well, non-trivial. 
Especially since you'll likely have quite a few ways to get to any 
path.

>A label in Basic, for example, works this way.  You can GOTO to a spot in the
>program defined by the label without the program having to "take" that
>location first.  Of course, this is not a continuation because you 
>are only changing
>the instruction pointer, not the bindings, call stack etc.  But I 
>can imagine a more
>robust sort of label which specifies not just a program location but 
>all the rest of
>the things that a continuation needs to know.  Does any such construct exist?

The best I can see happening is to be able to jump into a few levels 
of scope and have any lexicals automatically instantiate themselves, 
but past that I think you're out of luck, or I'm mis-understanding.

>Dan Sugalski wrote:
>
>>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