[Seaside-dev] thoughts on partial continuations

Julian Fitzell jfitzell at gmail.com
Wed Feb 4 16:21:35 UTC 2009


On Wed, Feb 4, 2009 at 3:58 PM, Lukas Renggli <renggli at gmail.com> wrote:

> I don't think that this is related with the use of partial
> continuations, because there is exactly the same problem with full
> continuations.


It's not specifically related to *partial* continuations, no. It's related
to using an exception to abort the callback after suspending it with #call:
(which we currently do with a partial continuation). #call: is using
continuations anyway. Why does it need to use an exception together with a
continuation to do its job?

Continuations (no matter what kind) and unwind blocks don't mix
> together. Should ensure blocks be unwound at all? When should they be
> unwound? How many times should they be unwound? You can change these
> property in the continuation and it probably solves this problem, but
> opens a bunch of other problems for sure. The only reasonable position
> to decide when to unwind is within the unwind block itself. I suggest
> not to go into that direction and just keep it with common wisdom:
> unwind blocks and continuations don't mix well.


I'm not talking about some some super-generic answer to how ensure blocks
and continuations should mix in every case. I'm talking about a very
specific case, which is the implementation of user callbacks in Seaside.
This is an interesting area of discussion (at least I find it interesting)
and if we kept with the common wisdom, Seaside never would have been created
in the first place. I'm not suggesting I have the answer all worked out but
there's no reason to believe that "the way things are" is the best they
could possibly be.

Think about the semantics here for a minute: the whole concept of doing a
#call: is that your callback is suspended, to be resumed later. I currently
can't think of any case when you would want an ensure block *inside* a
callback to be unwound on a #call:. Can you?

Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20090204/a75859ac/attachment.htm


More information about the seaside-dev mailing list