[Seaside-dev] Re: thoughts on partial continuations

[Julian Fitzell]

On Wed, Feb 4, 2009 at 7:10 PM, Dale Henrichs <dale.henrichs at gemstone.com>wrote:

>
> ----- "Julian Fitzell" <jfitzell at gmail.com> wrote:
>
> | And on a related note (not to distract from the original question), I
> don't
> | think WAPartialContinuation is as flexible as I would like; it's not
> quite
> | the power tool it could be. I'd like to be able to specify whether or not
> to
> | unwind to the marker (or to a different marker) when evaluating. I also
> | think it would be nice to be able to have an interface for evaluating and
> | creating where you can specify the context directly. The version that
> takes
> | a compiled method marker could be implemented on top of that.
> |
> | I know Dale has just got all his partial continuation tests passing. Will
> | your implementation allow some more flexibility here Dale or is that a
> big
> | pain?
> |
> | Julian
> |
>
> The current GemStone implementation uses stack-frame indexes:
>  1) create partial by copying frames x to Y
>  2) install partial at frame index z
>
> GemStone/S doesn't currently have a #thisContext, so determining which
> frame you are interested in can be an interesting problem - using a method
> as a marker makes it relatively straightforward to calculate the stack frame
> index. Without #thisContext, I think that we can still come up with
> functional alternatives without requiring changes to the primitives.


Excellent - It's very cool that you have it working.

As Lukas points out, whether the marker is a method or a context will end up
being platform-dependent anyway. As long as there's a way to use #foo as a
marker method when capturing and #bar as a marker method when evaluating
(this is not currently the case with the Squeak implementation), then what
you've got ought to be flexible enough for anything anyone can throw at it.
Though obviously specifying a point other than thisContext for Y could also
be handy.

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