object/method tailcalls ?
Patrick R. Michaud
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
> 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
> 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
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
> 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
> 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
> 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
> 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
> 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
> 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