Re: Tail method calls, can(), and pre-currying

2005-07-22 Thread Larry Wall
On Fri, Jul 22, 2005 at 07:04:24AM -0700, Brent 'Dax' Royal-Gordon wrote: : On 21/07/05, Adriano Ferreira <[EMAIL PROTECTED]> wrote: : > But is there any other case where we need an explicit tail call with "goto"? : : When the callee uses `caller Which we may not know, especially if we're tail-ca

Re: Tail method calls, can(), and pre-currying

2005-07-22 Thread Brent 'Dax' Royal-Gordon
On 21/07/05, Adriano Ferreira <[EMAIL PROTECTED]> wrote: > But is there any other case where we need an explicit tail call with "goto"? When the callee uses `caller -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker

Re: Tail method calls, can(), and pre-currying

2005-07-21 Thread Larry Wall
On Thu, Jul 21, 2005 at 11:58:41AM -0300, Adriano Ferreira wrote: : Larry said: : > So I guess I agree that .tailcall is probably just a bad synonym for "return". : : But is there any other case where we need an explicit tail call with "goto"? I suppose that depends on whether the tail-call opti

Re: Tail method calls, can(), and pre-currying

2005-07-21 Thread Adriano Ferreira
Larry said: > So I guess I agree that .tailcall is probably just a bad synonym for "return". But is there any other case where we need an explicit tail call with "goto"? And about a way to curry a method with its receiver to a sub, is there a shorthand? Thanks, Adriano.

Re: Tail method calls, can(), and pre-currying

2005-07-21 Thread Larry Wall
On Thu, Jul 21, 2005 at 09:59:57AM -0300, Adriano Ferreira wrote: : I can understand the convenience of turning a method into a subroutine : by currying the object. Syntactical support for this seems cool too. : But, can someone remind me why there is the need for an explicit tail : call syntax? It

Re: Tail method calls, can(), and pre-currying

2005-07-21 Thread Adriano Ferreira
On 7/20/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote: > Is there a Perl 6 tail call syntax, > One suggestion was a tweak of `can`'s definition: instead of returning > a reference to the method, it returns one with the invocant already > curried into it. Thus, the above becomes this: