object/method tailcalls ?

0 views
Skip to first unread message

Patrick R. Michaud

unread,
Apr 28, 2005, 10:08:07 PM4/28/05
to perl6-i...@perl.org
Is it (yet?) possible to use tailcalls from/to object methods?
I looked through the various pod files and couldn't find anything,
and I remember seeing some discussion about tailcalls in general
a couple of months ago but didn't stumble across the answers in the
archives.

I'd appreciate any gentle nudges towards the appropriate documentation,
source file, or answer. Thanks!

Pm

Leopold Toetsch

unread,
Apr 29, 2005, 6:20:25 AM4/29/05
to Patrick R. Michaud, perl6-i...@perl.org
Patrick R. Michaud <pmic...@pobox.com> wrote:
> Is it (yet?) possible to use tailcalls from/to object methods?

Well, there is a C<tailcallmethod> opcode in ops/object.ops. But I don't
know, if it works correctly.

$ find t -name '*.t' | xargs grep tailcall
t/pmc/sub.t: tailcall P0
t/pmc/sub.t: tailcall P0

That seems to be it what we have WRT tests :-(

> I looked through the various pod files and couldn't find anything,

$ perldoc -F docs/ops/object.pod

> I'd appreciate any gentle nudges towards the appropriate documentation,
> source file, or answer. Thanks!

Feedback and tests welcome. Thanks to you!

> Pm

leo

Leopold Toetsch

unread,
Apr 30, 2005, 4:40:12 AM4/30/05
to Patrick R. Michaud, perl6-i...@perl.org
Patrick R. Michaud <pmic...@pobox.com> wrote:

> I'd appreciate any gentle nudges towards the appropriate documentation,
> source file, or answer. Thanks!

I've now created a test for it in t/pmc/object-meths.t:

.sub go method
...
P2 = self
tailcallmethod "go"
.end

Works. But that's not really optimal. Should the invocant be implicitely
"self" and/or do we need a more general syntax:

.pcc_begin
.arg x
...
.invocant o
tailcallmethod "foo"
.pcc_end

And maybe even

foo(x, ...) @TAIL_CALL # tail function call

o.foo(x, ...) @TAIL_CALL # tail method call

> Pm

leo

Bob Rogers

unread,
Apr 30, 2005, 6:37:38 PM4/30/05
to l...@toetsch.at, Patrick R. Michaud, perl6-i...@perl.org
From: Leopold Toetsch <l...@toetsch.at>
Date: Sat, 30 Apr 2005 10:40:12 +0200

Patrick R. Michaud <pmic...@pobox.com> wrote:

> I'd appreciate any gentle nudges towards the appropriate documentation,
> source file, or answer. Thanks!

I've now created a test for it in t/pmc/object-meths.t:

.sub go method
...
P2 = self
tailcallmethod "go"
.end

Works. But that's not really optimal. Should the invocant be implicitely

"self" . . .

Why limit method tailcalls to self? Or to single dispatch?

. . . and/or do we need a more general syntax:

.pcc_begin
.arg x
...
.invocant o
tailcallmethod "foo"
.pcc_end

How about a unified ".pcc_tailcall" pseudo-op as an alternative to the
pcc_results production? That should cover all of the pcc_call cases at
once.

And maybe even

foo(x, ...) @TAIL_CALL # tail function call

o.foo(x, ...) @TAIL_CALL # tail method call

> Pm

leo

How about extending ".return" to cover these:

.return foo(x, ...) # tail function call

.return o.foo(x, ...) # tail method call

Otherwise, it may be easier to miss the fact that the call also does a
return. (This is close to what I suggested in the "Returning varying
numbers of results from a tail call" thread of 22-Feb-05, but on
reflection I think it would be better not to introduce another
"dot-keyword.")

-- Bob Rogers
http://rgrjr.dyndns.org/

Patrick R. Michaud

unread,
Apr 30, 2005, 1:37:50 PM4/30/05
to Leopold Toetsch, perl6-i...@perl.org
On Sat, Apr 30, 2005 at 10:40:12AM +0200, Leopold Toetsch wrote:
> Patrick R. Michaud <pmic...@pobox.com> wrote:
>
> > I'd appreciate any gentle nudges towards the appropriate documentation,
> > source file, or answer. Thanks!
>
> I've now created a test for it in t/pmc/object-meths.t:
>
> .sub go method
> ...
> P2 = self
> tailcallmethod "go"
> .end
>
> Works. But that's not really optimal. Should the invocant be implicitely
> "self" and/or do we need a more general syntax:
>
> .pcc_begin
> .arg x
> ...
> .invocant o
> tailcallmethod "foo"
> .pcc_end

For my needs (PGE) I definitely need the ability to have a non-self
invocant and to pass parameters.

> And maybe even
>
> foo(x, ...) @TAIL_CALL # tail function call
>
> o.foo(x, ...) @TAIL_CALL # tail method call

This would be *really* nice. I'm assuming here that @TAIL_CALL also
causes the current routine's caller to receive back any return values
from o.foo(x,...) exactly as if this routine had returned it.

I can probably make the .pcc wrappers work when I get to that level
of optimization if that's what we have available. Just to make sure
I have it right, the code

(ret) = obj.match(w,x,y,z)
.return (ret)

then becomes

# tailcall version of obj.match(w,x,y,z)
.pcc_begin prototyped
.arg w
.arg x
.arg y
.arg z
P2 = obj
tailcallmethod "match"
.pcc_end

...?

Pm

Leopold Toetsch

unread,
May 1, 2005, 5:04:38 AM5/1/05
to Bob Rogers, perl6-i...@perl.org
Bob Rogers <rogers...@rgrjr.dyndns.org> wrote:

> How about extending ".return" to cover these:

> .return foo(x, ...) # tail function call

> .return o.foo(x, ...) # tail method call

> Otherwise, it may be easier to miss the fact that the call also does a
> return. (This is close to what I suggested in the "Returning varying
> numbers of results from a tail call" thread of 22-Feb-05, but on
> reflection I think it would be better not to introduce another
> "dot-keyword.")

Looks really nice and makes clear that the tailcall is a return
from the sub. I like it.

> -- Bob Rogers
> http://rgrjr.dyndns.org/

leo

Leopold Toetsch

unread,
May 1, 2005, 5:02:22 AM5/1/05
to Patrick R. Michaud, perl6-i...@perl.org
Patrick R. Michaud <pmic...@pobox.com> wrote:
> On Sat, Apr 30, 2005 at 10:40:12AM +0200, Leopold Toetsch wrote:

>> And maybe even
>>
>> foo(x, ...) @TAIL_CALL # tail function call
>>
>> o.foo(x, ...) @TAIL_CALL # tail method call

> This would be *really* nice. I'm assuming here that @TAIL_CALL also
> causes the current routine's caller to receive back any return values
> from o.foo(x,...) exactly as if this routine had returned it.

Yep.

> I can probably make the .pcc wrappers work when I get to that level
> of optimization if that's what we have available. Just to make sure
> I have it right, the code

> (ret) = obj.match(w,x,y,z)
> .return (ret)

> then becomes

> # tailcall version of obj.match(w,x,y,z)
> .pcc_begin prototyped
> .arg w
> .arg x
> .arg y
> .arg z
> P2 = obj

it's:

.invocant obj

> tailcallmethod "match"
> .pcc_end

Rest is fine.

> Pm

leo

Leopold Toetsch

unread,
May 3, 2005, 10:26:52 AM5/3/05
to Bob Rogers, Patrick R. Michaud, perl6-i...@perl.org
Bob Rogers wrote:

> How about extending ".return" to cover these:
>
> .return foo(x, ...) # tail function call
>
> .return o.foo(x, ...) # tail method call

Done - rev 7959.

More tests are welcome, as always. See imcc/t/syn/tail.t for existing ones.

leo

Patrick R. Michaud

unread,
May 4, 2005, 9:58:17 PM5/4/05
to Leopold Toetsch, Bob Rogers, perl6-i...@perl.org
On Tue, May 03, 2005 at 04:26:52PM +0200, Leopold Toetsch wrote:
> Bob Rogers wrote:
>
> >How about extending ".return" to cover these:
> >
> > .return foo(x, ...) # tail function call
> >
> > .return o.foo(x, ...) # tail method call
>
> Done - rev 7959.

Excellent, thanks Leo. Does this mean we can retire
RT ticket #31681 ?

Also, I tried to close ticket # 35052 ( "PGE doesn't link" ),
but apparently I lack sufficient knowledge or magic bits to
accomplish that. Any help on this would be appreciated.

Pm

Leopold Toetsch

unread,
May 5, 2005, 5:05:32 AM5/5/05
to Patrick R. Michaud, perl6-i...@perl.org
Patrick R. Michaud wrote:
> On Tue, May 03, 2005 at 04:26:52PM +0200, Leopold Toetsch wrote:
>
>>Bob Rogers wrote:
>>
>>
>>>How about extending ".return" to cover these:
>>>
>>> .return foo(x, ...) # tail function call
>>>
>>> .return o.foo(x, ...) # tail method call
>>
>>Done - rev 7959.
>
>
> Excellent, thanks Leo. Does this mean we can retire
> RT ticket #31681 ?

Yep. I've set it to "resolved".

> Also, I tried to close ticket # 35052 ( "PGE doesn't link" ),
> but apparently I lack sufficient knowledge or magic bits to
> accomplish that. Any help on this would be appreciated.

There used to be a "closed" status. Dunno.

>
> Pm

leo

Reply all
Reply to author
Forward
0 new messages