Consider this: 

perl -MO=Deparse,-p
print $x= "hi";
chomp $x= "hi";
chop $x= "hi";
sprintf $x= "hi";
printf $x= "hi";
reverse $x= "hi";
join $x= "hi";
unlink $x= "hi";
die $x= "hi";
warn $x= "hi";
__END__
print(($x = 'hi'));
(chomp($x) = 'hi');
(chop($x) = 'hi');
sprintf(($x = 'hi'));
printf(($x = 'hi'));
reverse(($x = 'hi'));
join(($x = 'hi'));
unlink(($x = 'hi'));
die(($x = 'hi'));
warn(($x = 'hi'));

[download]
Note how chomp and chop are the only ones that get parsed the way they do.

Quoting bits of perlman:perlop: 

    left    terms and list operators (leftward)
[...]
    right    = += -= *= etc.
[...]
    nonassoc    list operators (rightward)
[...]
=head2 Terms and List Operators (Leftward)
[...]

[download]
If any list operator (print(), etc.) or any unary operator (chdir(), etc.) is followed by a left parenthesis as the next token, the operator and arguments within parentheses are taken to be of highest precedence, just like a normal function call. 
[...]
=head2 List Operators (Rightward)

[download]
On the right side of a list operator, it has very low precedence,

So that means that list operators w/o parens around their arguments should bind less tightly than assignment operators. This is the case for all of the list operators I used in my sample code except for chop and chomp. I can't find anything special about those two core functions that would explain their special treatment.

This is made worse by the fact that chomp( @x )= whatever; doesn't generate an error like all of these do: 

chop( $x )= whatever;
chop( @x )= whatever;
chomp( $x )= whatever;

[download]
(I've already reported this last bug to p5p.) such that chomp my @input= <STDIN>; does nothing useful but reports no errors nor warnings (well, it declares @input and leaves it empty and then reads one line from STDIN and throws it away, most of which isn't useful).

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re: chop/chomp bind too tightly
by japhy (Canon) on Nov 14, 2001 at 23:48 UTC
    You'd find that pos() and vec() behave like chop() and chomp()... except that they're supposed to!

    _____________________________________________________
    Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
    s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

[reply]

      Neither pos nor vec are "list operators". I say this because I don't see "pos LIST" nor "vec LIST" in the "Synopsis" section of their respective documentation entries.

      I also checked     perl -e "print prototype('CORE::chomp')" for several of the items, but that appears to be a rather imperfect test.

      Perhaps it is the "chop VARIABLE" and "chomp VARIABLE" entries in their synopsis sections that (indirectly) explain this behavior?

              - tye (but my friends call me "Tye")
[reply]
[d/l]
Re: chop/chomp bind too tightly
by Anonymous Monk on Nov 15, 2001 at 00:19 UTC

    Note also, chomp() doesn't really act like a list operator when parens aren't used (unlike print(), warn(), reverse(), etc): 

    $ perl -MO=Deparse,-p -e 'chomp $a, $b'
(chomp($a), $b);
-e syntax OK

$ perl -MO=Deparse,-p -e 'warn $a, $b'
warn($a, $b);
-e syntax OK

$ perl -MO=Deparse,-p -e 'reverse $a, $b'
reverse($a, $b);
-e syntax OK

$ perl -MO=Deparse,-p -e 'print $a, $b'
print($a, $b);
-e syntax OK

    [download]
[reply]
[d/l]

      I had already realized that but having it restated so nicely made me realize that this certainly contradicts the documentation [at the least, "chop LIST" and "chomp LIST" would need to be changed to "chop( LIST )" and "chomp( LIST)"] so I've now reported this to p5p as a bug as well. Thanks.

              - tye (but my friends call me "Tye")
[reply]
Re: chop/chomp bind too tightly
by Zaxo (Archbishop) on Nov 15, 2001 at 02:52 UTC

    I think 'chomp VARIABLE' in the summary is accurate. Consider

    $ perl -we '($c,$d,$e)=("a$/", "b$/", "c$/");$g=chomp $c, $d, $e;print
+ $g,$c,$d,$e'
Useless use of a variable in void context at -e line 1.
Useless use of a variable in void context at -e line 1.
1ab
c
$ perl -we '($c,$d,$e)=("a$/", "b$/", "c$/");$g=chomp( $c, $d, $e);pri
+nt $g,$c,$d,$e'
3abc$

    [download]
    It appears that the parens create an unnamed array variable. One difference between chop/chomp and print is that the former modify their arguments and throw an exception if they are ro.

    Just another data point.

    After Compline,
    Zaxo

[reply]
[d/l]
[select]

Back to Meditations