Piers Cawley [EMAIL PROTECTED] wrote:
And, dammit, making a full continuation isn't something a programmer
should do lightly.
BTW I had to change your example code (you remember it for sure, it's in
t/op/gc_13 inv CVS)
(define (choose . all-choices)
(let ((old-fail fail))
Dan Sugalski [EMAIL PROTECTED] wrote:
$P1 = interpinfo .INTERPINFO_CURRENT_CONT
$P1 = clone $P1
I'm still inclined to make this sequence an opcode, though. The
cloning is still necessary, as the return continuation is returned.
Hrm. I think the returned continuation should be usable
* The stack frame caching is back, hopefully now implemented correctly:
1) when a return continuation is invoked the stack frame is recycled
2) when a continuation is created, all the return continuations up the
call chain are converted to real continuations by changing the
vtable.
At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote:
* The stack frame caching is back, hopefully now implemented correctly:
1) when a return continuation is invoked the stack frame is recycled
2) when a continuation is created, all the return continuations up the
call chain are converted to
All~
I don't like the idea of having to dig down through the entire return
chain promoting these guys. Is there a reason not to use DOD/GC to
recycle continuations?
Matt
On Tue, 2 Nov 2004 14:10:09 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote:
At 2:30 PM -0500 11/2/04, Matt Fowles wrote:
All~
I don't like the idea of having to dig down through the entire return
chain promoting these guys. Is there a reason not to use DOD/GC to
recycle continuations?
Yes. Speed.
While you can skip some of the digging (since you can stop at the
first
Dan Sugalski [EMAIL PROTECTED] writes:
At 2:30 PM -0500 11/2/04, Matt Fowles wrote:
All~
I don't like the idea of having to dig down through the entire return
chain promoting these guys. Is there a reason not to use DOD/GC to
recycle continuations?
Yes. Speed.
While you can skip some of
