[Seaside] Seaside Internals

[Avi Bryant]

On Mon, 8 Sep 2003, Stephen Pair wrote:

> Those links seem to only argue in favor of having continuations evaluate
> an unwind behavior.  Where are the arguments against?  I can't think of
> any reason why a normal use of continuations shouldn't invoke the unwind
> behavior of the calling (and terminating) stack.  In my opinion, any
> flow control contructs (non local returns, exception handling,
> continuations, etc) should honor requests to #ensure: (and friends).

Stephen,

The argument isn't really whether or not continuation invocations should
evaluate #ensure: blocks, but when or which ones.

The problem is that part of the contract of an ensure block is that it's
the *last* thing to get evaluated - when you have

[A] ensure: [B],

you expect B to only get evaluated once A is done - and it may well be
very broken to evaluate anything in A after B has done its thing.

But if I capture a continuation inside A, then exit from A (evaluating
B), I now have the power to do exactly that - jump back into the middle
of A.  And when you then leave again, does B get evaluated a second time,
a third?

So the general gist of those papers is to find a way such that B gets
evaluated exactly once, when you promise that you're truly done with A -
or, alternatively, to invalidate any continuations you've captured inside
A as soon as you evaluate B.

It's *not* as simple as just always evaluating B whenever you leave A (for
example by invoking another continuation).

In a Seaside context, my recommendation is simply this: *do not show a
page to a user from within a block that is protected by #ensure:*.  "[self
call: Foo] ensure: [...]" is just bad news.

> Btw, what about changing the protocol of continuations from #value to
> #resume (I think the arguments in favor of this change were that there
> is more of an expectation of non-normal flow control happening with
> #resume)?

For now it's too useful that they be polymorphic with blocks - I guess it
could have both #resume and #value...

>  Also, I'd like to see another method on a continuation that
> will create and schedule another process to resume a continuation (and
> leave the current stack alone)...maybe that's already there though.
> Something like:
>
> fork
>
>     [self resume] fork

You've got to be careful here - the Continuation class that comes with
Seaside is not thread safe, and it's not trivial to write one that is
(although if Anthony's "context tags" made it ito 3.6, that makes it
easier).

What's the common use you see for that?

> One of these days, we'll have to think about reconciling continuations
> and exception handling (where an exception would hold a continuation and
> a handler would run in a different branch off the same stack as the
> continuation (instead of being lopped onto the bottom of the stack)).

One of these days.  ;)