A listop, a block and a dot

[Miroslav Silovic]

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 after f doesn't change the behaviour (in either case). Is this
behaviour a bug in pugs? Should . bind stronger than non-parenthesised
function call regardless of slurpy?

Miro

Re: A listop, a block and a dot

[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 after f doesn't change the behaviour (in either case). Is this
 behaviour a bug in pugs? Should . bind stronger than non-parenthesised
 function call regardless of slurpy?

I think that's what it should do, yes.

Luke

Re: A listop, a block and a dot

[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}.()))



sub f([EMAIL PROTECTED]) { say @_; }
f {1}.(); # outputs block, tries to call a method from the return of say,
dies


Which is because now f is on the listop precedence above method postfix
and the parens are

  ((f {1}).())


Whitespace after f doesn't change the behaviour (in either case).


You mean in the defining special form? There I think is no
difference between 'sub f(' and 'sub f ('.


Is this
behaviour a bug in pugs? Should . bind stronger than non-parenthesised
function call regardless of slurpy?



I think that's what it should do, yes.


So you mean to lower listop in precedence below method postfix?
BTW, has listop always been top precedence? And where exactly should
it go? Actually there is a precedence level called 'list op (rightward)'
which in my eyes naturally is below comma which in turn is below the
assignment ops.
--
$TSa.greeting := HaloO; # mind the echo!

Re: A listop, a block and a dot

[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}.()))

((f {1}).())

Listop application has always had looser precedence than unary op
application.  Eg.

% perl -le 'print(length foo  4)'
1
% perl -le 'print 3  4'
1

With parentheses:

print((length foo)  4)
print(3  4)

So this was quite a disturbing bug.

Re: A listop, a block and a dot

[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 wrong?

/Autrijus/

Re: A listop, a block and a dot

[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