Re: A listop, a block and a dot

2005-10-05 Thread Luke Palmer
On 10/5/05, Autrijus Tang <[EMAIL PROTECTED]> wrote: > However: > f:{1}.() > > still parses as > > (&f(:{1})).() > > as the "adverbial block" form takes precedence. Is that also wrong? No, that seems right to me, much in the same way that: $x.{1}.{2} Binds to the left. Luke

Re: A listop, a block and a dot

2005-10-05 Thread Autrijus Tang
Luke Palmer wrote: With parentheses: print((length "foo") < 4) print(3 < 4) So this was quite a disturbing bug. This is now also quite a fixed bug. :-) However: f:{1}.() still parses as (&f(:{1})).() as the "adverbial block" form takes precedence. Is that also wro

Re: A listop, a block and a dot

2005-10-05 Thread Luke Palmer
On 10/5/05, TSa <[EMAIL PROTECTED]> wrote: > IIRC, this puts f into the named unary precedence level > which is below method postfix. We're trying to stop using the words "below" and "above" for precedence. Use "looser" and "tighter" instead, as there is not ambiguity with those. >(f ({1}.()

Re: A listop, a block and a dot

2005-10-05 Thread TSa
HaloO, Luke Palmer wrote: On 10/4/05, Miroslav Silovic <[EMAIL PROTECTED]> wrote: Playing with pugs, I ran into this corner case: sub f($x) { say $x; } f {1}.(); # ok, outputs 1 IIRC, this puts f into the named unary precedence level which is below method postfix. Thus we get (f ({1}.())

Re: A listop, a block and a dot

2005-10-05 Thread Luke Palmer
On 10/4/05, Miroslav Silovic <[EMAIL PROTECTED]> wrote: > Playing with pugs, I ran into this corner case: > > sub f($x) { say $x; } > f {1}.(); # ok, outputs 1 > > sub f([EMAIL PROTECTED]) { say @_; } > f {1}.(); # outputs block, tries to call a method from the return of say, > dies > > Whitespace