Re: Abstracting continuations

["Michael St. Hippolyte" <address@hidden>]

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.

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?

Michael

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