[Seaside-dev] Re: partial continuation implementation

[Lukas Renggli]

>> > 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.
>>
>> We do not provide power tools for stack manipulation, co-routines,
>> continuations, subcomputations, f-operators, ... Seaside is a web
>> framework and it should concentrate on the web framework things only.
>
> It's not useful to talk about what we don't provide here. We *do* provide an
> implementation of continuations and the current implementation is very
> geared to a specific way of implementing Flow. I would like to be able to
> experiment with the way we use it and currently it seems unnecessarily
> restrictive. There's absolutely no reason to hard-code the marker in the
> continuation - that is mixing the implementation of #answer: with the
> implementation of partial continuations. Can you give me some reason why it
> needs to be there?

Again, there is nothing hardcoded in the current implementation. The
user of the continuation decides what method to use as a marker. It
works perfectly for the current use cases. If you have a new use-case
that cannot be handled it is fine to improve it.

>> Now, if there are bugs in our specific continuation implementation
>> these should be obviously fixed in place. Please do not create a
>> continuation framework that can be reconfigured to solve all possible
>> problems of the world as well.
>
> I don't want a continuation framework. I want a continuation implementation
> that isn't implemented only to work in the current implementation of Flow.
> Particularly if Gemstone is doing VM modifications to make this work, it
> would be nice to have an implementation done properly the first time so we
> have some flexibility.

Again, WAPartialContinuation is within a platform specific package.
The only user is a platform specific method and a the platform
specific tests. Gemstone, VASt, GST, Dolphin, ... will use their own
implementation if they decide to support Seaside-Flow. Forcing more
flexibility does not help other platforms, it will only make porting
harder when we start to use this functionality.

Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch