Closed p5pRT closed 20 years ago
$ perl-devel -wle 'sub n { print @_; 3 } $foo = n - 1; print $foo' -1 3
$ perl-devel -wle 'sub n { print @_; 3 } $foo = n() - 1; print $foo'
2
Somebody convince me that this is the way the precedence rules are supposed to work out\, because right now it appears horribly wrong\, but its late.
$ perl-devel -wle 'sub n { print @_; 3 } $foo = n - 1; print $foo' -1 3
$ perl-devel -wle 'sub n { print @_; 3 } $foo = n() - 1; print $foo'
2
Somebody convince me that this is the way the precedence rules are supposed to work out\, because right now it appears horribly wrong\, but its late.
(Coincidentally\, I'm currently writing about subroutines.)
If "supposed to" means "are documented to"\, then try this from perlsub:
sub mygrep (&@) mygrep { /foo/ } $a\, $b\, $c sub myrand ($) myrand 42 sub mytime () mytime
Note how the last three examples in the table above are treated specially by the parser. C\<mygrep()> is parsed as a true list operator\, C\<myrand()> is parsed as a true unary operator with unary precedence the same as C\<rand()>\, and C\<mytime()> is truly without arguments\, just like C\<time()>. That is\, if you say
mytime +2;
you'll get C\<mytime() + 2>\, not C\<mytime(2)>\, which is how it would be parsed without a prototype.
If "supposed to work out" means "the Good\, Right and Intuitive Thing"\, then\, well\, who knows?
Simon
__END__
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review\, retransmission\, dissemination or other use of\, or taking of any action in reliance upon\, this information by persons or entities other than the intended recipient is prohibited. If you received this in error\, please contact the sender and delete the material from any computer.
Ooops. Finger trouble. Here it is again with the correct Subject:\, for the benefit of the perlbugtron.
schwern@blackrider.arena-i.com (Michael G Schwern) wrote
Somebody convince me that this is the way the precedence rules are supposed to work out\, because right now it appears horribly wrong\, but its late.
Normally a subroutine is syntactically the same as a list operator (rightwards). But if it has a prototype of ($)\, it's treated as a named unary operator. And a prototype of () is treated as a list operator (rightwards).
I can't find this said in so many words in the pods\, but an example in the Prototypes section of perlsub implies it:
Note how the last three examples above are treated specially by the parser. mygrep() is parsed as a true list operator\, myrand() is parsed as a true unary operator with unary precedence the same as rand()\, and mytime() is truly without arguments\, just like time(). That is\, if you say
mytime +2;
you'll get mytime() + 2\, not mytime(2)\, which is how it would be parsed without the prototype.
Mike Guy
On May 11\, Michael G Schwern said:
$ perl-devel -wle 'sub n { print @_; 3 } $foo = n - 1; print $foo' -1 3
$ perl-devel -wle 'sub n { print @_; 3 } $foo = n() - 1; print $foo'
2
This reminds me of an interesting precedence issue brought up on DALnet #perl.
$foo = 13; print $foo - 1; # prints 12 print $foo-1; # prints 12 print $foo -1; # prints -1 to the filehandle 13
The guy's problem was his use of whitespace.
"Michael" == Michael G Schwern \schwern@​blackrider\.arena\-i\.com writes: Michael> $ perl-devel -wle 'sub n { print @_; 3 } $foo = n - 1; Michael> print $foo' -1 3
This is parsed as '$foo = n (-1)'
Michael> $ perl-devel -wle 'sub n { print @_; 3 } $foo = n() - 1; Michael> print $foo'
This isn't.
Michael> Somebody convince me that this is the way the precedence Michael> rules are supposed to work out\, because right now it Michael> appears horribly wrong\, but its late.
It's always been this way. If you don't like the behaviour\, use an explicit prototype. Unprototyped subs default to a 'sub (@)' prototype.
@schwern - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#3233 (status was 'resolved')
Searchable as RT3233$