[squeak-dev] Continuations

I have what may be a silly question about continuations.  First, some  
background.

I'm about to give a lecture on Continuations.  I'm trying to model  
what the "functional people" do, just to show off the flexibility of  
Smalltalk.  I'm working in the Seaside one-click image, because,  
having introduced continuations, I want to talk about the way that  
they are used in Seaside to implement natural control flow.  So, I'm  
not trying to solve any particular programming problem

Here is a little example that I wrote to illustrate a continuations.

SeasideDemo >> countUpTo: initialInterruptValue
        "demonstrate resumable continuations"
        | interruptValue |
        interruptValue := initialInterruptValue.
        1 to: 1000
                do: [:i |
                        Transcript show: 'i = '.
                        Transcript show: i.
                        Transcript cr.
                        i = interruptValue
                                ifTrue: [interruptValue := Continuation
                                                currentDo: [:cc | ^ cc]]]



If I execute

        d := SeasideDemo new.
        c := d countUpTo: 7

in a workspace, I get

i = 1
i = 2
i = 3
i = 4
i = 5
i = 6
i = 7

in the Transcript, as you would expect.  Then the method returns, with  
a continuation, which I name c

I can then resume that continuation:

        c value: 12

and the count in the transcript goes

i = 8
i = 9
i = 10
i = 11
i = 12

as I would expect.  However, if I "doit" c value:12 a second time, the  
count resumes from 13, not from 8.  This surprised me.

Strangely, if instead of assigning the result of d countUpTo:7 to c, I  
just inspect it, and doIt

        self value: 12

in the inspector, then the count continues from 8 to 12.  I can doIt  
multiple times, and each time the count goes from 8 to 12.
However, what is strange is that I get a new inspector on a new  
continuation each time I doIt.  I can only infer that the initial  
"inspect It" has somehow been captured as part of the continuation.

I'm also confused to find that the result of

        c2 := c value: 15

is not a new continuation, that will count up from 15 but ... nil.

Are my expectations wrong?  Are there bugs in the Seaside  
implementation of Continuations?  Or what?

        Andrew



____________________________
Prof. Andrew P. Black
Department of Computer Science
Portland State University
Oregon, USA

http://www.cs.pdx.edu/~black
Telephone: +1 503 725 2411

> Are my expectations wrong?  Are there bugs in the Seaside implementation of
> Continuations?  Or what?

When you evaluate the line

   c := d countUpTo: 7

to capture the continuation the first time the answered continuation
includes the assignment to c, as well as the rest of the doIt or
printIt you used to evaluate the expression.

The first time you evaluate

    c value: 15

the code assigns a new continuation to c (one starting at 15) and ends
with the previous doIt. The next time you evaluate

    c value: 15

the continuation c is different, thus starts at 15 and counts up to 1000.

So as far as I understand, everything seems to be fine.

The problem could be solved by moving the assignment into the [ :cc |
^ cc ]-block and assigning to an inst-var or global.

Seaside 2.9 comes with partial continuations, where you could stop the
capture right before the assignment to avoid the problem.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Thank you.  In formulating my question, I had begun to think as  
much ... that the assignment was being captured and re-done.
Hence, the different behaviour with the inspector.  However, previous  
discussion (Subject: Scheme Continuations) had led me to believe that  
implicitly declared workspace variables were indeed treated like  
globals.

I still don't understand where the "nil" comes form, though.


On 11 Mar 2009, at 00:19, Lukas Renggli wrote:

> I still don't understand where the "nil" comes form, though.

When you evaluate a continuation the current computation is *aborted*
and the captured one is *resumed*.

Thus, when evaluating

    c2 := c value: 15

no assignment to c2 happens and the variable remains what it was before (nil).

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Ah, yes; thanks for the clear explanation.

On 11 Mar 2009, at 12:42, Lukas Renggli wrote: