[PROPOSAL] calling convention abstraction
Roger Hale
> 2.5) return context
>
> Yesterdays conversation on IRC (yes!) has clearly shown that the
> current calling conventions are lacking information about scalar vs
> list vs void context.
>
> sub foo { want.List ?? (1,2,3) :: 1 } # or some such
>
> This information could also be attached to @ARGS. E.g.
>
> @ARGS."return_list"(1)
Would it be possible to attach it to the continuation? Then in the
course of tail-calling the information continues to be available just
where it's needed.
Leopold Toetsch
> Leopold Toetsch wrote:
> > sub foo { want.List ?? (1,2,3) :: 1 } # or some such
> >
> > This information could also be attached to @ARGS. E.g.
> >
> > @ARGS."return_list"(1)
> Would it be possible to attach it to the continuation? Then in the
> course of tail-calling the information continues to be available just
> where it's needed.
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.
leo
Roger Hale
But as each tail-call supplies a new @ARGS, how can this be the case?
One can also think of {scalar, list, ...} context as the continuation's
signature...
Leopold Toetsch
> 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.
>>
>> leo
> 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.
> One can also think of {scalar, list, ...} context as the continuation's
> signature...
Yes.
leo
Roger Hale
> Roger Hale <roger...@rcn.com> 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.
>
>
> 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. 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, 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
Bob Rogers
Date: Thu, 07 Apr 2005 04:23:41 -0400
Leopold Toetsch wrote:
> Roger Hale <roger...@rcn.com> 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. So if @OUT_ARGS is used for other
things, then it's not a tail call.
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], and cannot
have different @OUT_ARGS from the call to B, because B never regains
control when C returns. Your notation in that case has to be:
B(@IN_ARGS 1)[c10n: A*] calls C(@OUT_ARGS 1)[c10n: A*]
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.
-- 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.
Roger Hale
> From: Roger Hale <roger...@rcn.com>
> Date: Thu, 07 Apr 2005 04:23:41 -0400
>
> Leopold Toetsch wrote:
> > Roger Hale <roger...@rcn.com> 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
Bob Rogers
Date: Mon, 11 Apr 2005 09:30:32 -0400
Bob Rogers wrote:
> From: Roger Hale <roger...@rcn.com>
> Date: Thu, 07 Apr 2005 04:23:41 -0400
>
> Leopold Toetsch wrote:
> > Roger Hale <roger...@rcn.com> 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.
My mistake; I had thought "@OUT_ARGS" meant "results". I see I didn't
read Leo's original proposal carefully enough, and you were just
following his terminology; my apologies. I agree that information about
return context can't live in @ARGS (in or out) directly.
> . . . 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.
So it sounds like we are all saying the same thing now?
-- Bob
Roger Hale
> So it sounds like we are all saying the same thing now?
Well, two of us at least (with me coming from the peanut gallery)... Leo
has his own say, and it's his proposal.
regards,
Roger