Skip Menu |
Report information
Id: 127391
Status: pending release
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: wolf-dietrich_moeller [at] t-online.de
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)

Attachments
127391-0001-Improve-documentation-of-operator-precedence-and-ass.patch



From: Wolf-Dietrich Moeller (Munchen) <wolf-dietrich_moeller [...] t-online.de>
To: <perlbug [...] perl.org>
Subject: possible inconsistency in "perlop" documentation on associativity of operators
Date: Wed, 27 Jan 2016 17:32:17 +0100
Download (untitled) / with headers
text/plain 1.5k

Hello,

I am not sure if the following issue in the “perlop”-documentation needs clarification.

 

In the section on “Operator Precedence and Associativity” there is the line:

“right       = += -= *= etc. goto last next redo dump”
The “etc.” means to me that all other assignment operators are also right-associative, i.e. in particular also the short-circuit “&&=”, “||=” and “//=”.
 
Taking the explanation in the section on “Assignment Operators” (further below in perlop), the example given there for a “combined operator” can be extended to a sequence of operators with “&&=”:
    $y &&= $x += 2is equivalent to    $y = $y && ($x = $x + 2);
Given the short-circuit behavior of ‘&&’, it is clear that the assignment “($x = $x + 2)” in the “equivalent assignment” (right) is not executed if $y == 0 (and correctly the “simple” assignment ‘$y = ’ is right-associative).
But looking to the “original assignment” (left), where $y only appears to the left of the “&&=” operator, the (effective) associativity for this “&&=” operator is “left”. 
 
This is counter-intuitive to the text in the documentation given above, that ALL assignment operators are right-associative.
It seems to me that this only applies if a “combined” operator is separated into the equivalent form with “simple” operators; but then it is no longer the “combined” assignment operator.
Should this be reflected somewhere in the documentation (in the section on “Operator Precedence and Associativity”)?
 
This issue is not related to any particular Perl version, as I found the same text already in my old Perl 5.0 Manpages.
 
Best regards
Wolf Moeller
From: Lukas Mai <plokinom [...] gmail.com>
Date: Wed, 27 Jan 2016 22:45:03 +0100
To: perl5-porters [...] perl.org
Subject: Re: [perl #127391] possible inconsistency in "perlop" documentation on associativity of operators
Download (untitled) / with headers
text/plain 1.5k
Am 27.01.2016 um 17:32 schrieb Wolf-Dietrich Moeller (via RT): Show quoted text
> # New Ticket Created by Wolf-Dietrich Moeller > # Please include the string: [perl #127391] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=127391 > > > > Hello, > I am not sure if the following issue in the "perlop"-documentation needs > clarification. > > In the section on "Operator Precedence and Associativity" there is the line: > "right = += -= *= etc. goto last next redo dump" > The "etc." means to me that all other assignment operators are also > right-associative, i.e. in particular also the short-circuit "&&=", "||=" > and "//=". > > Taking the explanation in the section on "Assignment Operators" (further > below in perlop), the example given there for a "combined operator" can be > extended to a sequence of operators with "&&=": > $y &&= $x += 2; is equivalent to $y = $y && ($x = $x + 2); > Given the short-circuit behavior of '&&', it is clear that the assignment > "($x = $x + 2)" in the "equivalent assignment" (right) is not executed if $y > == 0 (and correctly the "simple" assignment '$y = ' is right-associative).
OK so far. Show quoted text
> But looking to the "original assignment" (left), where $y only appears to > the left of the "&&=" operator, the (effective) associativity for this "&&=" > operator is "left".
I don't understand this at all. If &&= and += were left associative, then $y &&= $x += 2 would be parsed as ($y &&= $x) += 2, which is clearly not the case. What do you mean by effective associativity? -- Lukas Mai <plokinom@gmail.com>
To: <perlbug-followup [...] perl.org>
Subject: RE: [perl #127391] possible inconsistency in "perlop" documentation on associativity of operators
From: Wolf-Dietrich Moeller (München) <wolf-dietrich_moeller [...] t-online.de>
Date: Fri, 29 Jan 2016 00:33:34 +0100
Download (untitled) / with headers
text/plain 3.3k
Hi Lukas, thanks for the fast response. The perlop-documentation specifies associativity as (citation): "Operator associativity defines what happens if a sequence of the same operators is used one after another: whether the evaluator will evaluate the left operations first, or the right first." Perhaps my example mislead you, as I did not show a sequence of the SAME operators (sorry for that). But please look at the following test program: ############ my $x = 3; my $y = 0; my $z = 6; $x &&= $y &&= $z &&= 7; print "x=$x y=$y z=$z"; ########### The result with my Perl 5.22.1 is: x=0 y=0 z=6 ############ Taking the specification for associativity cited above, evaluation should start with the rightmost operator, as all 3 operators are &&= (sequence of same operators). And then $z should be 7 and not 6, as $z was preset to 6 (== true), and "$z &&= 7" results in 7. The second evaluation should be for "$y &&= $z", which correctly yields $y == 0, as $y was preset to 0. Last the first operator should be evaluated, which correctly yields $x == 0, as $y == 0. So for the &&= operator to be "right-associative" according to the specification cited above, I am missing the evaluation of the rightmost operator. Thus the associativity of &&= must be something else. I wrote "effective left-associative", as I studied electrical engineering, and not computer science, and thus I am not sure if this behaviour of &&= is really called left-associative, or something else by CS guys. Hope this clarifies my issue. Best regards Wolf Show quoted text
-----Original Message----- From: Lukas Mai via RT [mailto:perlbug-followup@perl.org] Sent: Mittwoch, 27. Januar 2016 22:46 To: wolf-dietrich_moeller@t-online.de Subject: Re: [perl #127391] possible inconsistency in "perlop" documentation on associativity of operators Am 27.01.2016 um 17:32 schrieb Wolf-Dietrich Moeller (via RT):
> # New Ticket Created by Wolf-Dietrich Moeller > # Please include the string: [perl #127391] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=127391 > > > > Hello, > I am not sure if the following issue in the "perlop"-documentation needs > clarification. > > In the section on "Operator Precedence and Associativity" there is the line: > "right = += -= *= etc. goto last next redo dump" > The "etc." means to me that all other assignment operators are also > right-associative, i.e. in particular also the short-circuit "&&=", "||=" > and "//=". > > Taking the explanation in the section on "Assignment Operators" (further > below in perlop), the example given there for a "combined operator" can be > extended to a sequence of operators with "&&=": > $y &&= $x += 2; is equivalent to $y = $y && ($x = $x + 2); > Given the short-circuit behavior of '&&', it is clear that the assignment > "($x = $x + 2)" in the "equivalent assignment" (right) is not executed if $y > == 0 (and correctly the "simple" assignment '$y = ' is right-associative).
OK so far.
> But looking to the "original assignment" (left), where $y only appears to > the left of the "&&=" operator, the (effective) associativity for this "&&=" > operator is "left".
I don't understand this at all. If &&= and += were left associative, then $y &&= $x += 2 would be parsed as ($y &&= $x) += 2, which is clearly not the case. What do you mean by effective associativity? -- Lukas Mai <plokinom@gmail.com>
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #127391] possible inconsistency in "perlop" documentation on associativity of operators
Date: Fri, 29 Jan 2016 17:53:28 +0000
Download (untitled) / with headers
text/plain 2.7k
Wolf-Dietrich Moeller wrote: Show quoted text
>Taking the specification for associativity cited above, evaluation >should start with the rightmost operator,
This is a misunderstanding of operator precedence. Precedence resolves the syntactic ambiguity to determine grouping, *not* order of evaluation. Order of evaluation is a semantic matter, determined by the meaning of the operators. Sometimes precedence is described in terms of order of evaluation, but that correspondence only works in situations where all the operators evaluate all of their operands and the actual order of evaluation of the subexpressions doesn't make any difference. In your example, the expression $x &&= $y &&= $z &&= 7 by virtue of precedence groups as $x &&= ($y &&= ($z &&= 7)) In evaluation, the operator having greatest control is always the top-level one. In this case, the top-level operator is the leftmost &&=. It sees that its lhs $x is true, so decides to evaluate its rhs and assign the result to $x. Its rhs is $y &&= ($z &&= 7) The top-level operator here is the middle &&= of the original expression. It sees that its lhs $y is false, and so decides not to evaluate its rhs and not to modify $y. Therefore the rightmost &&= never gets control. $z is therefore never in danger of being modified. The middle &&= yields the false value of $y as the value of the $y&&= expression, and the leftmost (top-level) &&= assigns that value to $x. Hence the result that you see. Everything is operating correctly. Show quoted text
>I wrote "effective left-associative", as I studied electrical >engineering, and not computer science, and thus I am not sure if this >behaviour of &&= is really called left-associative, or something else >by CS guys.
It's not left-associative. If it were, then the expression you wrote would group as (($x &&= $y) &&= $z) &&= 7 This is a valid expression, and does not behave the same as the right-associated version. It happens to produce the same answer as the right-associated version given the starting values in your example, but the two give different answers if you start with a different set of values, such as $x=3, $y=6, $z=0. Using an &&= expression as the lhs of an assignment is quite unusual, and its behaviour is liable to be surprising, so don't worry too much about understanding it. The distinctive behaviour of &&= that you mistakenly described as effective left-associativity is really its selective evaluation of its rhs. But even operators that evaluate all their operands do so in a specific order, which has nothing to do with precedence: $ perl -e '(print 1) + (print 2) + (print 3); print "\n"' 123 $ perl -e '(print 1) ** (print 2) ** (print 3); print "\n"' 123 In this example, both + and ** evaluate their operands from left to right, even though + is left-associative and ** is right-associative. -zefram
Subject: RE: [perl #127391] possible inconsistency in "perlop" documentation on associativity of operators
To: <perlbug-followup [...] perl.org>
From: Wolf-Dietrich Moeller (München) <wolf-dietrich_moeller [...] t-online.de>
Date: Sat, 30 Jan 2016 17:59:35 +0100
Download (untitled) / with headers
text/plain 1.3k
Hi Zefram, thanks for your explanation. You write that describing associativity in terms of order of evaluation is only true " where all the operators **evaluate all of their operands** and the actual order of evaluation of the subexpressions doesn't make any difference ". Do I understand you correctly, that you imply that the existing text in the perlop-documentation is wrong for the combined operators with short-circuit operations (&&=, ||= and //=), where not all operands are evaluated by the operator? The existing text reads (cited): "Operator associativity defines what happens if a sequence of the same operators is used one after another: whether the evaluator will **evaluate** the left operations first, or the right first. For example, in 8 - 4 - 2, subtraction is left associative so Perl evaluates the expression left to right. 8 - 4 is evaluated first making the expression 4 - 2 == 2 and not 8 - 2 == 6." (I agree that for the example of subtraction given there the wording with "evaluation" is correct, but it is wrong for the case of combined operators with short-circuit behavior.) Should this text instead be adapted to refer to "grouping" instead of "evaluation", or should there be an additional sentence catering for the special case of combined operators with short-circuit behaviour? This would resolve the issue I raised. Best regards Wolf
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Date: Mon, 1 Feb 2016 17:29:17 +0000
Subject: Re: [perl #127391] possible inconsistency in "perlop" documentation on associativity of operators
Download (untitled) / with headers
text/plain 2.9k
Wolf-Dietrich Moeller wrote: Show quoted text
>Do I understand you correctly, that you imply that the existing text >in the perlop-documentation is wrong for the combined operators with >short-circuit operations (&&=, ||= and //=), where not all operands are >evaluated by the operator?
Ah yes, the text you quote (and the preceding paragraph about precedence) is indeed incorrect for short-circuiting operators. Show quoted text
>Should this text instead be adapted to refer to "grouping" instead of >"evaluation", or should there be an additional sentence catering for >the special case of combined operators with short-circuit behaviour?
I'd rather not treat short-circuiting as a special case, because it's not, for this purpose. If anything the special case is the simple operators, and that's probably worth bringing out explicitly. I suggest those two paragraphs should become I<Operator precedence> means some operators group more tightly than others. For example, in C<2 + 4 * 5>, the multiplication has higher precedence, so C<4 * 5> is grouped together as the right-hand operand of the addition, rather than C<2 + 4> being grouped together as the left-hand operand of the multiplication. It is as if the expression were written C<2 + (4 * 5)>, not C<(2 + 4) * 5>. So the expression yields C<2 + 20 == 22>, rather than C<6 * 5 == 30>. I<Operator associativity> defines what happens if a sequence of the same operators is used one after another: whether they will be grouped at the left or the right. For example, in C<9 - 3 - 2>, subtraction is left associative, so C<9 - 3> is grouped together as the left-hand operand of the second subtraction, rather than C<3 - 2> being grouped together as the right-hand operand of the first subtraction. It is as if the expression were written C<(9 - 3) - 2>, not C<9 - (3 - 2)>. So the expression yields C<6 - 2 == 4>, rather than C<9 - 1 == 8>. For simple operators that evaluate all their operands and then combine the values in some way, precedence and associativity (and parentheses) imply some ordering requirements on those combining operations. For example, in C<2 + 4 * 5>, the grouping implied by precedence means that the multiplication of 4 and 5 must be performed before the addition of 2 and 20, simply because the result of that multiplication is required as one of the operands of the addition. But the order of operations is not fully determined by this: in C<2 * 2 + 4 * 5> both multiplications must be performed before the addition, but the grouping does not say anything about the order in which the two multiplications are performed. In fact Perl has a general rule that the operands of an operator are evaluated in left-to-right order. A few operators such as C<&&=> have special evaluation rules that can result in an operand not being evaluated at all; in general, the top-level operator in an expression has control of operand evaluation. -zefram
Date: Sat, 6 Feb 2016 21:39:03 +0100
From: Wolf-Dietrich Moeller (München) <wolf-dietrich_moeller [...] t-online.de>
To: <perlbug-followup [...] perl.org>
Subject: RE: [perl #127391] possible inconsistency in "perlop" documentation on associativity of operators
Download (untitled) / with headers
text/plain 503b
Zefram wrote: Show quoted text
>I'd rather not treat short-circuiting as a special case, because it's not, >for this purpose. If anything the special case is the simple operators, >and that's probably worth bringing out explicitly. I suggest those two >paragraphs should become ....
I agree with the text you suggest to replace the existing text in perlop-documentation. This now clearly shows behaviour as specified and implemented in Perl. I think this should go into the forthcoming version of Perl. Thanks Wolf
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 3.3k
On Mon Feb 01 09:29:42 2016, zefram@fysh.org wrote: Show quoted text
> Wolf-Dietrich Moeller wrote:
> >Do I understand you correctly, that you imply that the existing text > >in the perlop-documentation is wrong for the combined operators with > >short-circuit operations (&&=, ||= and //=), where not all operands are > >evaluated by the operator?
> > Ah yes, the text you quote (and the preceding paragraph about precedence) > is indeed incorrect for short-circuiting operators. >
> >Should this text instead be adapted to refer to "grouping" instead of > >"evaluation", or should there be an additional sentence catering for > >the special case of combined operators with short-circuit behaviour?
> > I'd rather not treat short-circuiting as a special case, because it's not, > for this purpose. If anything the special case is the simple operators, > and that's probably worth bringing out explicitly. I suggest those two > paragraphs should become > > I<Operator precedence> means some operators group more tightly than > others. For example, in C<2 + 4 * 5>, the multiplication has higher > precedence, so C<4 * 5> is grouped together as the right-hand operand > of the addition, rather than C<2 + 4> being grouped together as the > left-hand operand of the multiplication. It is as if the expression > were written C<2 + (4 * 5)>, not C<(2 + 4) * 5>. So the expression > yields C<2 + 20 == 22>, rather than C<6 * 5 == 30>. > > I<Operator associativity> defines what happens if a sequence of the > same operators is used one after another: whether they will be grouped > at the left or the right. For example, in C<9 - 3 - 2>, subtraction > is left associative, so C<9 - 3> is grouped together as the left-hand > operand of the second subtraction, rather than C<3 - 2> being grouped > together as the right-hand operand of the first subtraction. It is > as if the expression were written C<(9 - 3) - 2>, not C<9 - (3 - 2)>. > So the expression yields C<6 - 2 == 4>, rather than C<9 - 1 == 8>. > > For simple operators that evaluate all their operands and then > combine the values in some way, precedence and associativity (and > parentheses) imply some ordering requirements on those combining > operations. For example, in C<2 + 4 * 5>, the grouping implied by > precedence means that the multiplication of 4 and 5 must be performed > before the addition of 2 and 20, simply because the result of that > multiplication is required as one of the operands of the addition. > But the order of operations is not fully determined by this: in C<2 * > 2 + 4 * 5> both multiplications must be performed before the addition, > but the grouping does not say anything about the order in which the > two multiplications are performed. In fact Perl has a general rule > that the operands of an operator are evaluated in left-to-right order. > A few operators such as C<&&=> have special evaluation rules that > can result in an operand not being evaluated at all; in general, the > top-level operator in an expression has control of operand evaluation. > > -zefram >
In order to move this ticket toward resolution I've formatted Zefram's recommendation into a patch attached to this ticket. Please discuss so that we know whether we want to apply this in 5.25.1. Thank you very much. -- James E Keenan (jkeenan@cpan.org)
Subject: 127391-0001-Improve-documentation-of-operator-precedence-and-ass.patch
From fc6fe274f70057369f007f92305e3a31ae706a68 Mon Sep 17 00:00:00 2001 From: Zefram <zefram@fysh.org> Date: Wed, 20 Apr 2016 22:00:09 -0400 Subject: [PATCH] Improve documentation of operator precedence and associativity. For RT #127391 --- pod/perlop.pod | 42 +++++++++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 11 deletions(-) diff --git a/pod/perlop.pod b/pod/perlop.pod index 17d24bb..ef47b45 100644 --- a/pod/perlop.pod +++ b/pod/perlop.pod @@ -27,17 +27,37 @@ X<operator, precedence> X<precedence> X<associativity> Operator precedence and associativity work in Perl more or less like they do in mathematics. -I<Operator precedence> means some operators are evaluated before -others. For example, in S<C<2 + 4 * 5>>, the multiplication has higher -precedence so S<C<4 * 5>> is evaluated first yielding S<C<2 + 20 == -22>> and not S<C<6 * 5 == 30>>. - -I<Operator associativity> defines what happens if a sequence of the -same operators is used one after another: whether the evaluator will -evaluate the left operations first, or the right first. For example, in -S<C<8 - 4 - 2>>, subtraction is left associative so Perl evaluates the -expression left to right. S<C<8 - 4>> is evaluated first making the -expression S<C<4 - 2 == 2>> and not S<C<8 - 2 == 6>>. +I<Operator precedence> means some operators group more tightly than others. +For example, in C<2 + 4 * 5>, the multiplication has higher precedence, so C<4 +* 5> is grouped together as the right-hand operand of the addition, rather +than C<2 + 4> being grouped together as the left-hand operand of the +multiplication. It is as if the expression were written C<2 + (4 * 5)>, not +C<(2 + 4) * 5>. So the expression yields C<2 + 20 == 22>, rather than +C<6 * 5 == 30>. + +I<Operator associativity> defines what happens if a sequence of the same +operators is used one after another: whether they will be grouped at the left +or the right. For example, in C<9 - 3 - 2>, subtraction is left associative, +so C<9 - 3> is grouped together as the left-hand operand of the second +subtraction, rather than C<3 - 2> being grouped together as the right-hand +operand of the first subtraction. It is as if the expression were written +C<(9 - 3) - 2>, not C<9 - (3 - 2)>. So the expression yields C<6 - 2 == 4>, +rather than C<9 - 1 == 8>. + +For simple operators that evaluate all their operands and then combine the +values in some way, precedence and associativity (and parentheses) imply some +ordering requirements on those combining operations. For example, in C<2 + 4 * +5>, the grouping implied by precedence means that the multiplication of 4 and +5 must be performed before the addition of 2 and 20, simply because the result +of that multiplication is required as one of the operands of the addition. But +the order of operations is not fully determined by this: in C<2 * 2 + 4 * 5> +both multiplications must be performed before the addition, but the grouping +does not say anything about the order in which the two multiplications are +performed. In fact Perl has a general rule that the operands of an operator +are evaluated in left-to-right order. A few operators such as C<&&=> have +special evaluation rules that can result in an operand not being evaluated at +all; in general, the top-level operator in an expression has control of +operand evaluation. Perl operators have the following associativity and precedence, listed from highest precedence to lowest. Operators borrowed from -- 1.9.1
Date: Thu, 21 Apr 2016 09:24:20 +0200
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
From: demerphq <demerphq [...] gmail.com>
CC: Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: [perl #127391] possible inconsistency in "perlop" documentation on associativity of operators
Download (untitled) / with headers
text/plain 7.2k
I vote yes. On 21 April 2016 at 04:05, James E Keenan via RT <perlbug-followup@perl.org> wrote: Show quoted text
> On Mon Feb 01 09:29:42 2016, zefram@fysh.org wrote:
>> Wolf-Dietrich Moeller wrote:
>> >Do I understand you correctly, that you imply that the existing text >> >in the perlop-documentation is wrong for the combined operators with >> >short-circuit operations (&&=, ||= and //=), where not all operands are >> >evaluated by the operator?
>> >> Ah yes, the text you quote (and the preceding paragraph about precedence) >> is indeed incorrect for short-circuiting operators. >>
>> >Should this text instead be adapted to refer to "grouping" instead of >> >"evaluation", or should there be an additional sentence catering for >> >the special case of combined operators with short-circuit behaviour?
>> >> I'd rather not treat short-circuiting as a special case, because it's not, >> for this purpose. If anything the special case is the simple operators, >> and that's probably worth bringing out explicitly. I suggest those two >> paragraphs should become >> >> I<Operator precedence> means some operators group more tightly than >> others. For example, in C<2 + 4 * 5>, the multiplication has higher >> precedence, so C<4 * 5> is grouped together as the right-hand operand >> of the addition, rather than C<2 + 4> being grouped together as the >> left-hand operand of the multiplication. It is as if the expression >> were written C<2 + (4 * 5)>, not C<(2 + 4) * 5>. So the expression >> yields C<2 + 20 == 22>, rather than C<6 * 5 == 30>. >> >> I<Operator associativity> defines what happens if a sequence of the >> same operators is used one after another: whether they will be grouped >> at the left or the right. For example, in C<9 - 3 - 2>, subtraction >> is left associative, so C<9 - 3> is grouped together as the left-hand >> operand of the second subtraction, rather than C<3 - 2> being grouped >> together as the right-hand operand of the first subtraction. It is >> as if the expression were written C<(9 - 3) - 2>, not C<9 - (3 - 2)>. >> So the expression yields C<6 - 2 == 4>, rather than C<9 - 1 == 8>. >> >> For simple operators that evaluate all their operands and then >> combine the values in some way, precedence and associativity (and >> parentheses) imply some ordering requirements on those combining >> operations. For example, in C<2 + 4 * 5>, the grouping implied by >> precedence means that the multiplication of 4 and 5 must be performed >> before the addition of 2 and 20, simply because the result of that >> multiplication is required as one of the operands of the addition. >> But the order of operations is not fully determined by this: in C<2 * >> 2 + 4 * 5> both multiplications must be performed before the addition, >> but the grouping does not say anything about the order in which the >> two multiplications are performed. In fact Perl has a general rule >> that the operands of an operator are evaluated in left-to-right order. >> A few operators such as C<&&=> have special evaluation rules that >> can result in an operand not being evaluated at all; in general, the >> top-level operator in an expression has control of operand evaluation. >> >> -zefram >>
> > In order to move this ticket toward resolution I've formatted Zefram's recommendation into a patch attached to this ticket. > > Please discuss so that we know whether we want to apply this in 5.25.1. > > Thank you very much. > > -- > James E Keenan (jkeenan@cpan.org) > > --- > via perlbug: queue: perl5 status: open > https://rt.perl.org/Ticket/Display.html?id=127391 > > From fc6fe274f70057369f007f92305e3a31ae706a68 Mon Sep 17 00:00:00 2001 > From: Zefram <zefram@fysh.org> > Date: Wed, 20 Apr 2016 22:00:09 -0400 > Subject: [PATCH] Improve documentation of operator precedence and > associativity. > > For RT #127391 > --- > pod/perlop.pod | 42 +++++++++++++++++++++++++++++++----------- > 1 file changed, 31 insertions(+), 11 deletions(-) > > diff --git a/pod/perlop.pod b/pod/perlop.pod > index 17d24bb..ef47b45 100644 > --- a/pod/perlop.pod > +++ b/pod/perlop.pod > @@ -27,17 +27,37 @@ X<operator, precedence> X<precedence> X<associativity> > Operator precedence and associativity work in Perl more or less like > they do in mathematics. > > -I<Operator precedence> means some operators are evaluated before > -others. For example, in S<C<2 + 4 * 5>>, the multiplication has higher > -precedence so S<C<4 * 5>> is evaluated first yielding S<C<2 + 20 == > -22>> and not S<C<6 * 5 == 30>>. > - > -I<Operator associativity> defines what happens if a sequence of the > -same operators is used one after another: whether the evaluator will > -evaluate the left operations first, or the right first. For example, in > -S<C<8 - 4 - 2>>, subtraction is left associative so Perl evaluates the > -expression left to right. S<C<8 - 4>> is evaluated first making the > -expression S<C<4 - 2 == 2>> and not S<C<8 - 2 == 6>>. > +I<Operator precedence> means some operators group more tightly than others. > +For example, in C<2 + 4 * 5>, the multiplication has higher precedence, so C<4 > +* 5> is grouped together as the right-hand operand of the addition, rather > +than C<2 + 4> being grouped together as the left-hand operand of the > +multiplication. It is as if the expression were written C<2 + (4 * 5)>, not > +C<(2 + 4) * 5>. So the expression yields C<2 + 20 == 22>, rather than > +C<6 * 5 == 30>. > + > +I<Operator associativity> defines what happens if a sequence of the same > +operators is used one after another: whether they will be grouped at the left > +or the right. For example, in C<9 - 3 - 2>, subtraction is left associative, > +so C<9 - 3> is grouped together as the left-hand operand of the second > +subtraction, rather than C<3 - 2> being grouped together as the right-hand > +operand of the first subtraction. It is as if the expression were written > +C<(9 - 3) - 2>, not C<9 - (3 - 2)>. So the expression yields C<6 - 2 == 4>, > +rather than C<9 - 1 == 8>. > + > +For simple operators that evaluate all their operands and then combine the > +values in some way, precedence and associativity (and parentheses) imply some > +ordering requirements on those combining operations. For example, in C<2 + 4 * > +5>, the grouping implied by precedence means that the multiplication of 4 and > +5 must be performed before the addition of 2 and 20, simply because the result > +of that multiplication is required as one of the operands of the addition. But > +the order of operations is not fully determined by this: in C<2 * 2 + 4 * 5> > +both multiplications must be performed before the addition, but the grouping > +does not say anything about the order in which the two multiplications are > +performed. In fact Perl has a general rule that the operands of an operator > +are evaluated in left-to-right order. A few operators such as C<&&=> have > +special evaluation rules that can result in an operand not being evaluated at > +all; in general, the top-level operator in an expression has control of > +operand evaluation. > > Perl operators have the following associativity and precedence, > listed from highest precedence to lowest. Operators borrowed from > -- > 1.9.1 > >
-- perl -Mre=debug -e "/just|another|perl|hacker/"
CC: Perl RT Bug Tracker <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
To: demerphq <demerphq [...] gmail.com>
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #127391] possible inconsistency in "perlop" documentation on associativity of operators
Date: Mon, 20 Jun 2016 09:55:19 +0100
Download (untitled) / with headers
text/plain 444b
Show quoted text
> On 21 April 2016 at 04:05, James E Keenan via RT
> > In order to move this ticket toward resolution I've formatted Zefram's recommendation into a patch attached to this ticket. > > > > Please discuss so that we know whether we want to apply this in 5.25.1.
On Thu, Apr 21, 2016 at 09:24:20AM +0200, demerphq wrote: Show quoted text
> I vote yes.
Me too. -- "You may not work around any technical limitations in the software" -- Windows Vista license
From: Wolf-Dietrich Moeller (München) <wolf-dietrich_moeller [...] t-online.de>
To: <perlbug-followup [...] perl.org>
Date: Fri, 24 Nov 2017 15:25:28 +0100
Subject: RE: [perl #127391] possible inconsistency in "perlop" documentation on associativity of operators
Download (untitled) / with headers
text/plain 943b
What happened to this proposal? As of Perl 5.26, the text in perlop is still the old text, which is wrong with respect to the short-circuiting operators "&&=", "||=" and "//=". I think this should be included in Perl 5.28. Wolf Show quoted text
-----Original Message----- From: Dave Mitchell via RT [mailto:perlbug-followup@perl.org] Sent: Montag, 20. Juni 2016 11:05 To: wolf-dietrich_moeller@t-online.de Subject: Re: [perl #127391] possible inconsistency in "perlop" documentation on associativity of operators
> On 21 April 2016 at 04:05, James E Keenan via RT
> > In order to move this ticket toward resolution I've formatted Zefram's recommendation into a patch attached to this ticket. > > > > Please discuss so that we know whether we want to apply this in 5.25.1.
On Thu, Apr 21, 2016 at 09:24:20AM +0200, demerphq wrote:
> I vote yes.
Me too. -- "You may not work around any technical limitations in the software" -- Windows Vista license
Subject: Re: [perl #127391] possible inconsistency in "perlop" documentation on associativity of operators
From: Zefram <zefram [...] fysh.org>
To: perl5-porters [...] perl.org
Date: Tue, 5 Dec 2017 19:21:29 +0000
Download (untitled) / with headers
text/plain 205b
Wolf-Dietrich Moeller (Munchen) wrote: Show quoted text
>What happened to this proposal?
It got dropped on the floor, sorry. I've now patched the documentation in commit 3c0dbbbaeb55e36a6beabd1cfc9f0432053bcaf0. -zefram


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org