RE: Demystifying Continuations

["David Simmons" <address@hidden>]

"Michael Lucas-Smith" <michaell@spiritshigh.com> wrote in message
news:3C9AF7F1.2020406@spiritshigh.com...
> 
> > I did not mean to imply that continuations always need to be copied.
> > Everything you've described just re-inforces my understanding that
> > continuations are just activation record chains (contexts).
> > 
> > I had, however, been led to believe that continuation style
execution did
> > allow one to implement threading. And that one of the "fork/spawn"
> > techniques was to allow continuations to be copied. Which means that
they
> > can be returned through twice. This is the difference between a
downward
> > continuation and one that is not a downward continuation?
> > 
> 
> Yes, you're right. I missed that part of continuations. When a second 
> call is made to the continuation, all the context frames need to be 
> copied, otherwise the two threads will be sharing state, which could
be 
> very bad :)
> 
> > The "copying" can be performed lazily so that it is only done when a
> > "copied" continuation is actually returned through. But I still had
the
> > impression that this capability was needed.
> > 
> > If not, then continuations seem different and less useful than
contexts.
> > 
> > Am I still correct that one can effectively say "return to this
> > continuation". Which (while it there are multiple ways to implement
it), the
> > net effect is that of replacing that calling context with the given
> > continuation and then returning [which is the unwind and goto effect
you're
> > describing].
> 
> Not replacing the calling context.
> 
> methodZ->
> methodA (pass continuation)->
> methodB: aContinuation->
> methodC: aContinuation->
> methodD: aContinuation->
> methodE: aContinuation->
> methodF: aContinuation->
> methodG: aContinuation (call continuation)->
> methodA
> 
> So you see in this example, you actually replace #methodB:, not 
> #methodF:, since we'll want to unwind to #methodZ, not #methodE.
> Methods B through F simply 'disappear' :)
> 
> Continuations make explicit, the implicit continuation in method
calls. 
> Implicitely, when you call methodB from methodA, you return to
methodA. 
> In continuations, you explicitely tell methodB to go to methodA.
> 
> In effect, every time you call a method in Smalltalk, there is a
hidden 
> continuation that is called every time you send the ^ bytecode, or get

> to the end of the method.

Ahh. Now we are getting to what I really wanted to understand properly.
I had presumed correctly that we replace the return context with the
provided continuation. What I had not realized was the temporal "set"
semantics that require us to unwind/remove intervening continuations.

This model is then "exactly" like a block far-return or an exception
unwinding sequence. Where, the F-B contexts/frames are not just
discarded. They "must" be unwound to preserve any guard/finally handler
semantics.

Which means that call-continuation is not that of "replacing" the
default return continuation. It is actually a case of throw/unwind until
the given continuation.

In the SmallScript VM there are a number of types of context exit
mechanisms. 

a) Return to a given context: (1) delta relative frames away, or (2) a
specific context object.

b) return from a given context: (1) delta relative frames away, or (2) a
specific context object.

These two mechanisms are used to implement all exception handling,
non-local block returns, goto, break, continue, redo, subroutines, etc.
===============

Next semantics question:

Can I call an arbitrary continuation (not in my call-chain set)? 

In other words, if the continuation I call is not part of my current
call-activation-chain, what happens to the current chain.

One of the following...
a) The current chain is effectively unwound to its root and then
replaced by the new continuation.

b) provided continuation is copied and grafted on to the tail of the
current chain and then we continue.

c) The current chain is suspended/abandoned and we just jump to the new
continuation. ** This mode has very significant semantic problems with
respect to guard handlers/finally operations **

I'm assuming the answer is "c", and that a disjoint continuation
represents a different thread. Which in turn means there are no unwind
operations to perform since we are actually performing a thread-switch
(where a call-activation-chain represents a thread).

-- Dave S. [www.smallscript.org]

> 
> Michael
>