[PROPOSAL] calling convention abstraction

0 views
Skip to first unread message

Leopold Toetsch

unread,
Mar 29, 2005, 5:28:09 AM3/29/05
to Perl 6 Internals
Below inline attached is a scheme for an abstraction layer around
calling conventions.

Comments welcome,
leo

CALL.txt

Roger Hale

unread,
Apr 2, 2005, 10:20:44 PM4/2/05
to perl6-i...@perl.org

> 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

unread,
Apr 3, 2005, 12:12:40 PM4/3/05
to Roger Hale, perl6-i...@perl.org
Roger Hale <r...@theworld.com> wrote:
> 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

unread,
Apr 3, 2005, 1:11:55 PM4/3/05
to perl6-i...@perl.org

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

unread,
Apr 4, 2005, 3:41:03 AM4/4/05
to Roger Hale, perl6-i...@perl.org
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.
>>
>> 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

unread,
Apr 7, 2005, 4:23:41 AM4/7/05
to perl6-i...@perl.org
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. 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

unread,
Apr 7, 2005, 10:54:32 PM4/7/05
to Roger Hale, perl6-i...@perl.org
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. 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

unread,
Apr 11, 2005, 9:30:32 AM4/11/05
to perl6-i...@perl.org, Bob Rogers, Roger Hale
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.

>
> 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

unread,
Apr 12, 2005, 10:05:11 PM4/12/05
to Roger Hale, perl6-i...@perl.org
From: Roger Hale <roger...@rcn.com>
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

unread,
Apr 13, 2005, 1:39:16 AM4/13/05
to perl6-i...@perl.org, Bob Rogers, Roger Hale
Bob Rogers wrote:
> 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

Reply all
Reply to author
Forward
0 new messages