Evalulation order during concat changed #16597
Comments
From @JRaspassCreated by @JRaspassThis is a bug report for perl from jraspass@gmail.com, ----------------------------------------------------------------- cat poc.pl; perl poc.pl; perl2 poc.pl Perl Info |
From @xenuOn Mon, 25 Jun 2018 04:46:07 -0700
I'm not 100% sure if it's relevant, but perlop says: Note that just as in C, Perl doesn't define when the variable is incremented or decremented. You just know it will be done sometime before or after the value is returned. This also means that modifying a variable twice in the same statement will lead to undefined behavior. |
|
The RT System itself - Status changed from 'new' to 'open' |
From @AbigailOn Tue, Jun 26, 2018 at 01:54:27AM +0200, Tomasz Konojacki wrote:
I'd argue that the 5.28.0 version is more correct than the 5.26.1 one. Note also that I cannot reproduce this. Running this with various versions #!/opt/perl/bin/perl use 5.010; use strict; my $n = 1; __END__ Abigail |
From @JRaspassLooks like you used commas rather than periods. But yes I agree, the docs On Tue, 26 Jun 2018, 18:21 Abigail, <abigail@abigail.be> wrote:
|
From @AbigailOn Tue, Jun 26, 2018 at 07:27:42PM +0200, Abigail wrote:
And it does. It seems I cannot read.
And again, I cannot read. The original used '.', not ','. And v5.18.4 1 0 which is a change of behaviour -- but as Tomasz indicated, it's a Abigail |
From @AbigailOn Tue, Jun 26, 2018 at 06:25:29PM +0100, James Raspass wrote:
Yeah, I noticed that half a second after I hit send. Abigail |
From wolf-dietrich_moeller@t-online.deHi, Please see the following: #### test program #### #### output test program #### As 'concat' operation is left-associative (see perlop-documentation), Now in Perl 5.28 with the MULTI_CONCAT this execution model For me the test program above does not violate any requirements Wolf |
From @iabynOn Fri, Aug 10, 2018 at 06:24:56PM +0200, Wolf-Dietrich Moeller (Munchen) wrote:
The issue here is what order (if any) does perl guarantee sub-expressions ($a+$b) * ($c*$d) does perl guarantee that the first addition will take place before the -- |
From @davidnicolI don't think it's possible to interpret perldoc perlop's *Operator precedence* means some operators are evaluated before others. For *Operator associativity* defines what happens if a sequence of the same in a way that allows the right side of a left-associative operation to be Dot has always been documented as left associative, making Moeller's result (the rest of this e-mail is half-baked) How heavy would the modification to the multiconcat code be to allow How big of a change is recategorizing Dot as non-associative instead of Here's a reasonable (contrived for this message, but reasonable) use which my $line_number = 1; for my $thing (@ListOfThingsThatTakeFourLinesToOutput){ # all the line methods return lines ending with newlines. print $line_number++.' '.$thing->first_line() .$line_number++.' '.$thing->second_line() .$line_number++.' '.$thing->third_line() .$line_number++.' '.$thing->fourth_line(); } On Fri, Aug 10, 2018 at 12:56 PM Dave Mitchell <davem@iabyn.com> wrote:
-- |
From @GrinnzOn Fri, Aug 10, 2018 at 4:08 PM David Nicol <davidnicol@gmail.com> wrote:
There's a third option, which is to not apply the optimization (or apply -Dan |
From Eirik-Berg.Hanssen@allverden.noOn Fri, Aug 10, 2018 at 10:08 PM David Nicol <davidnicol@gmail.com> wrote:
Oh, yes it is: The docs for associativity here speak of the order in In C<< $e.$f.($f = 'FF') >>, the left-most concatenation is, per the If I recall correctly (and it hasn't changed since last this topic was Eirik |
From @sisyphusOn Fri, 10 Aug 2018 14:21:02 -0700, Eirik-Berg.Hanssen@allverden.no wrote:
Which would mean that for $x=8, $y=4, the expression "$x - $y - ($y=2)" could acceptably evaluate to 4 ? If the docs don't already specify the order in which the operands will be evaluated, then perhaps they ought to - even if it's just to state that the order is undefined. Cheers, |
From wolf-dietrich_moeller@t-online.deResent because of problems. Sorry -----Original Message----- David cited the old perlop doc (up to Perl 5.26). This documentation One sentence there reads: Eirik, did you consider this new text? Wolf |
From Eirik-Berg.Hanssen@allverden.noOn Sat, Aug 11, 2018 at 12:58 PM Wolf-Dietrich Moeller (München) <
No, sorry; I was unaware of it. That might be a game changer. Or not; the new text is still pretty vague, and don't strictly match the Reading that ticket, I get the impression of a failure to properly This example demonstrates that the left-hand operand is evaluated _after_ eirik@greencat[15:26:12] ... assuming that did not also change? (I don't have a new perl here; Eirik |
From @iabynOn Sat, Aug 11, 2018 at 03:36:15PM +0200, Eirik Berg Hanssen wrote:
There's also an example just with a concat mutator, where the order of sub TIESCALAR { bless [ $_[1] ]; } my ($a,$b,$c); $a .= $b; with $a .= $b, you get: FETCH(A) with $a .= $b . $c you get FETCH(B) Note how it changes from FETCHing the LHS first to the RHS first. This isn't an example of ordering of operand execution inconsistency, -- |
From @davidnicolOn Sat, Aug 11, 2018 at 10:40 AM Dave Mitchell <davem@iabyn.com> wrote:
Attached, and here in-line, is a revised proposed patch to the Inline Patchdiff -r 67f5ed179113 pod/perlop.pod
--- a/pod/perlop.pod Mon Aug 13 11:57:05 2018 -0500
+++ b/pod/perlop.pod Thu Aug 23 13:18:07 2018 -0500
@@ -389,6 +389,16 @@
X<->
Binary C<"."> concatenates two strings.
+
+As of version 5.28, a series of terms joined by C<"."> operators are
+evaluated prior to all getting concatenated, rather than the first
+two getting joined, followed by each additional in its own binary
+operation. This affects the result when the terms return aliases that
+get modified in later terms, such as preincremented scalars. Prior to
+version 5.28, aliasing issues only affected the first term in a series
+of concatenations, as the left side of the second and later operations
+was the unaliased result of the previous binary operation.
+
X<string, concatenation> X<concatenation>
X<cat> X<concat> X<concatenate> X<.>
-- "At this point, given the limited available data, certainty about only a |
From @davidnicolmulticoncatdoc_dln_20180823A.patchdiff -r 67f5ed179113 pod/perlop.pod
--- a/pod/perlop.pod Mon Aug 13 11:57:05 2018 -0500
+++ b/pod/perlop.pod Thu Aug 23 13:19:01 2018 -0500
@@ -389,6 +389,16 @@
X<->
Binary C<"."> concatenates two strings.
+
+As of version 5.28, a series of terms joined by C<"."> operators are
+evaluated prior to all getting concatenated, rather than the first
+two getting joined, followed by each additional in its own binary
+operation. This affects the result when the terms return aliases that
+get modified in later terms, such as preincremented scalars. Prior to
+version 5.28, aliasing issues only affected the first term in a series
+of concatenations, as the left side of the second and later operations
+was the unaliased result of the previous binary operation.
+
X<string, concatenation> X<concatenation>
X<cat> X<concat> X<concatenate> X<.>
|
From @davidnicolMade it shorter: Inline Patch--- a/pod/perlop.pod Mon Aug 13 11:57:05 2018 -0500
+++ b/pod/perlop.pod Thu Aug 23 14:35:46 2018 -0500
@@ -389,6 +389,13 @@
X<->
Binary C<"."> concatenates two strings.
+
+A series of terms joined by C<"."> operators are evaluated prior to
+all getting concatenated in a single operation. Prior to version 5.28,
+aliasing issues only affected the value of the first term in a series
+of concatenations, as the left side of the second and later operations
+was the intermediate result of the previous binary operation.
+
X<string, concatenation> X<concatenation>
X<cat> X<concat> X<concatenate> X<.>
|
From @iabynOn Thu, Aug 23, 2018 at 02:39:08PM -0500, David Nicol wrote:
What this documentation patch does, is change what was undefined I don't want the internal (and possibly changeable) details of an But the actual details of the ordering are much more complicated than ( f1() . f2() ) . ( f3() . f4() ) The order is actually equivalent to $tmp1 = f1(); Would you have predicted that? Does your text describe that? Could you In conclusion, I don't think the pod for the concatenation op should -- |
From @xsawyerxOn 08/24/2018 11:38 AM, Dave Mitchell wrote:
The documentation could specify the lack of guarantee. That would remove "The order in which concatenated expressions is undefined and should not (Or some better phrasing.) |
Migrated from rt.perl.org#133301 (status was 'open')
Searchable as RT133301$
The text was updated successfully, but these errors were encountered: