[plt-scheme] Understanding continuations

From: Anton van Straaten (anton at appsolutions.com)
Date: Sat Jul 19 18:08:14 EDT 2008

Grant Rettke wrote:
> I'm trying to visualize and understand continuations (this part of the
> work in another thread [Confusing continuation behavior (a question
> about)]).
> 
> If I write:
> 
> #lang scheme
> (define cont #f)
> (define (foo)
>   (call/cc
>    (lambda (arg-cont)
>      (set! cont arg-cont)))
>   13)
> (+ 1 2 3 (foo))
> 
> Could I visualize the continuation as?
> 
> (lambda (argument)
>   (+ 1 2 3 13))

You could, but you should be aware that this is an optimized version of 
the continuation.  The questions you've asked below might be answered 
more easily and precisely if you had a more detailed representation of 
the continuation, which at the very least should include a reference to 
'argument' (other than its binding).  Where does that reference belong?

Also, the fact that the continuation involves some code in the body of 
foo and some code in the outer expression (the call to "+") isn't 
reflected in your version of the continuation.  That would need a more 
detailed analysis which is probably best done after converting the code 
to CPS.

> If I write:
> 
> #lang scheme
> (define cont #f)
> (define (foo)
>   (call/cc
>    (lambda (arg-cont)
>      (set! cont arg-cont)
>      13)))
> (+ 1 2 3 (foo))
> 
> Could I visualize the continuation as?
> 
> (lambda (argument)
>   (+ 1 2 3 argument))

Yes, with similar caveats.

> The difference between the two is this:
> 
> 1. In the first one, the saved continuation 'cont' will always have
> the same value; that of the current continuation with the value of 13
> passed in to it. Every time that continuation is applied the result
> will be the same. It is like memoization.

In the first example, foo is a function that always returns 13, and the 
continuation that's captured inside foo does the same.  This is not so 
much memoization as a continuation involving a function that returns a 
constant value.

> 2. In the second one, the continuation is awaiting a value of the
> function foo 

In both cases, the continuation is awaiting a value.  This is very 
important to understand if you want to solve the bug we've been 
discussing.  The differences between the two cases relate to what 
happens to the value that the continuation receives.

> (or it is waiting for the expression of the call/cc
> block). So at any other point, that continuation could be passed
> "something else".

Again, this is all true in both cases.

> In the first one, "what happens next" could never change, because it
> has been determined. 

That's about right: what happens next is that 13 is passed to foo's 
(implicit) continuation.

> In the second one, "what happens next" could
> change, because the continuation is still waiting for a value.
> 
> Is that right?

See if you can restate it taking into account the fact that both 
continuations expect, and receive, a value.

Anton



Posted on the users mailing list.