On Sep 24, 2004, at 1:13 AM, Leopold Toetsch wrote:
Piers Cawley <[EMAIL PROTECTED]> wrote:
I could be wrong here, but it seems to me that having a special
'tailinvoke' operator which simply reuses the current return
continuation instead of creating a new one would make for rather faster
tail calls than fetching the current continuation out of the interpreter
structure, then invoking the target sub with with this new
continuation (ISTM that doing it this way means you're going to end up
doing a chunk of the work of creating a new return continuation anyway,
which rather defeats the purpose.)
Yep, that's true. We already have (unimplemented) C<tailcallmethod> opcodes. A plain C<tailcall> for functions is still missing. Anyway, if the current continuation has its location in the interpreter context, its simple to implement these opcodes.
You mentioned:
Well, basically, if an interpreter template is used (hanging off the subroutine), the previous interpreter template is the return continuation.
So this occurred to me: Not sure if it would be useful, but since you'd be able to trace back up the call stack, a tailcall for functions could take a numeric parameter, to let you invoke a continuation from further back in the stack, without having had to pass it in as an explicit parameter. So for instance:
return_cc ==> alias for call_cc_indexed 0
tailcall ==> alias for call_cc_indexed 1
call_cc_indexed 2 ==> invoke the continuation from 2 frames back, as though it had been passed down
It's just a generalization--it lets you do the equivalent of grabbing the current continuation, and passing that to a function which passes it to a function which passes it to a function...which invokes it, without having to ever create a real PMC.
But I'm not sure if that's a useful design pattern.
JEff
