From: Roger Hale <[EMAIL PROTECTED]> Date: Thu, 07 Apr 2005 04:23:41 -0400
Leopold Toetsch wrote:
> Roger Hale <[EMAIL PROTECTED]> wrote:
> >>Leopold Toetsch wrote:
>>
>>>As @ARGS (or @IN_ARGS, @OUT_ARGS) is being stored in the context, and
>>>that context is defacto the continuation, yes - a tail-call would
>>>inherit this information.
> >>But as each tail-call supplies a new @ARGS, how can this be the case?
> > We would have two parts in the context: @IN_ARGS, @OUT_ARGS. The
> C<tailcall> opcode can preserve that part with the return context.
It seems to me that both @IN_ARGS and @OUT_ARGS get used for other things (the tail-calls' arguments) in a chain of tail-calls.
The definition of a tail call is that it returns its callee's results
back to its caller unmodified.
Agreed, but...
So if @OUT_ARGS is used for other things, then it's not a tail call.
I don't understand. @OUT_ARGS aren't the arguments returned (to my understanding), they're the arguments to the next function in sequence.
Consider this chain:
A calls B(@OUT_ARGS 1)[continuation: A*] in context c
B(@IN_ARGS 1)[c10n: A*] calls C(@OUT_ARGS 2)[c10n: A*]
C(@IN_ARGS 2)[c10n: A*] wants to know context c, as it's getting ready to return something. Neither @IN_ARGS (the arguments C received from B) nor @OUT_ARGS (the arguments of any call C may make) has this information . . .
I don't think this is a real situation. If B passes C the continuation
it got from A, then the call to C is indeed a tail call [1],
Yes...
and cannot
have different @OUT_ARGS from the call to B, because B never regains
control when C returns.
I don't see what this has to do with the continuation passed with the call. A tail call is an arbitrary call with arbitrary arguments, in final position before returning. (If it omitted the tail-call optimization and supplied a continuation B* of its own, B* would be the identity stub
-> @return_args { A* @return_args }as it were; but these are not B's @OUT_ARGS, but B*'s @IN_ARGS and @OUT_ARGS, and A*'s @IN_ARGS, to my understanding.) B can call C with anything it likes, because it still has control before calling C.
Your notation in that case has to be:
B(@IN_ARGS 1)[c10n: A*] calls C(@OUT_ARGS 1)[c10n: A*]
What forces B to call C with the same arguments it was called with?
Or do you mean something different from a tail call? If so, could you please express it in a programming language?
. . . but the continuation (I propose) does; and this continues to be good for whoever wants to know: the return object holds the return context.
No?
regards, Roger
I believe so, but I think this is what Leo meant by "... that context is defacto the continuation." There doesn't need to be a separate "return object" because it would be one-to-one with the continuation.
Sorry, by "return object" I was only meaning the continuation; you are quite right. Just using a different term for parallelism with "return context", but I see it only introduced confusion.
-- Bob Rogers http://rgrjr.dyndns.org/
[1] If not implemented via "tailcall", it would use an additional stack frame, but the semantics would otherwise be identical.
Agreed.
(I apologize for my slow turn-around on replying; I hope to respond quicker in the future.)
-- Roger Hale
