RE: Demystifying Continuations

["David Simmons" <address@hidden>]

*** 
The following is forwarded from the comp.lang.smallscript.design
newsgroup.
***

> 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.
> 

Continuations are usually talked about in Procedural language settings, 
not Object Oriented settings. Specifically because a continuation is 
easily implemented as a goto.

One of the reasons the picture becomes complex in the OO world is 
because of all the throw/unwind logic. For historical purposes, I would 
say that a 'normal' continuation would NOT unwind, but would indeed
replace.

I believe this behaviour, from your arguments so far, would be 
inappropriete in an Object Oriented language. Calling a continuation 
within your execution thread should do a throw/unwind.

One of the reasons that threads aren't unwound is because if the 
continuation is not from your execution thread (ie; you've picked it up 
from an instance variable or some place else) then you don't need to 
waste time unwinding back through the last 50,000,000 threads. You can 
simple throw them away. This is extremely effecient. But it may not be 
entirely 'correct' in the object world.

So you have a choice. You can implement continuations with inconsistent 
behaviour by having it do two things:
(a) within the current thread, unwind back to the continuation frame
(b) within another thread, don't unwind, but jump straight to the 
continuation frame.

(I'll just throw in another thought for you. We've all seen people with 
memory problems because they hold on to things that shouldn't be held on

to. Like, a window on a class variable, or the root object on a class 
variable.. things like that. Imagine for a second somebody holding 
continuations about!)

Or you can have consistent continuations that really do behave like a 
procedural language and never unwind, but jump straight to the 
continuation frame.

As you've pointed out, this approach would have significant impacts on 
the handler code of SmallScript. This would actually give you something 
of an 'aspect' oriented programming approach. Using continuations you 
could override several programming features to give you a new aspect on 
parts of the system. I'm sure this would play havoc on the security and 
managed features of SmallScript.

Here's another thought if you want to preserve unwind behaviour. How do 
you handle your execution stack? I know if I'd written a process stack, 
I would be modifying it as I go. Lets say we've got a multithreaded 
continuation happening. Thread A sets the continuation for itself and 
keeps on running.

Thread B tried to call the continuation - it's now too late to do a lazy

copy. You needed to copy the entire thread stack when thread A set the 
continuation somewhere. This is extremely costly and reduces the 
benefits of continuations.

Of course, if you decide to ignore the unwind problems, then you won't 
have to copy the entire thread's execution stack.

In short I'd say you have some options and decisions to make. I'm 
guessing you really want to add continuations as a tick in the box to 
SmallScript. But it may not be a feasable feature for a secure Object 
Oriented Agents System.

Michael