<br><br><div class="gmail_quote">On Wed, Feb 4, 2009 at 7:10 PM, Dale Henrichs <span dir="ltr"><<a href="mailto:dale.henrichs@gemstone.com">dale.henrichs@gemstone.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"><br>
----- "Julian Fitzell" <<a href="mailto:jfitzell@gmail.com">jfitzell@gmail.com</a>> wrote:<br>
<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>
</div><div class="Ih2E3d">| the power tool it could be. I'd like to be able to specify whether or not to<br>
| unwind to the marker (or to a different marker) when evaluating. I also<br>
| think it would be nice to be able to have an interface for evaluating and<br>
| creating where you can specify the context directly. The version that takes<br>
| a compiled method marker could be implemented on top of that.<br>
|<br>
| I know Dale has just got all his partial continuation tests passing. Will<br>
| your implementation allow some more flexibility here Dale or is that a big<br>
| pain?<br>
|<br>
| Julian<br>
|<br>
<br>
</div>The current GemStone implementation uses stack-frame indexes:<br>
1) create partial by copying frames x to Y<br>
2) install partial at frame index z<br>
<br>
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.</blockquote>
<div><br>Excellent - It's very cool that you have it working.<br><br>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.<br>
</div></div><br>Julian<br>