<div class="gmail_quote">On Wed, Feb 4, 2009 at 3:37 PM, Lukas Renggli <span dir="ltr"><<a href="mailto:renggli@gmail.com">renggli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wed, Feb 4, 2009 at 1:42 PM, Julian Fitzell <<a href="mailto:jfitzell@gmail.com">jfitzell@gmail.com</a>> wrote:<br>
> And on a related note (not to distract from the original question), I don't<br>
> think WAPartialContinuation is as flexible as I would like; it's not quite<br>
> the power tool it could be.<br>
<br>
</div>We do not provide power tools for stack manipulation, co-routines,<br>
continuations, subcomputations, f-operators, ... Seaside is a web<br>
framework and it should concentrate on the web framework things only.</blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
We do not even mention continuations on the website. I believe this to<br>
be vital for Seaside, because continuations are just an implementation<br>
detail and considered to be scary and incomprehensible by the majority<br>
of people.<br>
</blockquote><div><br>That's fine. Nobody said we had to mention it on the website.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Now, if there are bugs in our specific continuation implementation<br>
these should be obviously fixed in place. Please do not create a<br>
continuation framework that can be reconfigured to solve all possible<br>
problems of the world as well.<br>
</blockquote></div><br>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.<br>
<br>Julian<br>