develooper Front page | perl.perl5.porters | Postings from August 2018

Re: [perl #133301] Evalulation order during concat changed

Thread Previous | Thread Next
From:
David Nicol
Date:
August 10, 2018 20:07
Subject:
Re: [perl #133301] Evalulation order during concat changed
Message ID:
12361_1533931649_5B6DF081_12361_5_1_CAFwScO8CW0Jr3PKd9-tpVQx9YK8N1WyL4tS0cRTHP_86VuVi9w@mail.gmail.com
I don't think it's possible to interpret perldoc perlop's

*Operator precedence* means some operators are evaluated before others. For
example, in 2 + 4 * 5 , the multiplication has higher precedence so 4 * 5 is
evaluated first yielding 2 + 20 == 22 and not 6 * 5 == 30 .

*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 == 2and not 8 -
2 == 6 .

in a way that allows the right side of a left-associative operation to be
evaluated first and still conform with the documentation.

Dot has always been documented as left associative, making Moeller's result
a bug.

(the rest of this e-mail is half-baked)

How heavy would the modification to the multiconcat code be to allow
"snapshots" that would upgrade to copies of the before state when a thing
gets modified later on, instead of simple aliases? I'm guessing just using
copies everywhere would defeat the purpose of the initiative.

How big of a change is recategorizing Dot as non-associative instead of
left-associative? I think huge, in that any code written to rely on the
associativity will not work after upgrade.


Here's a reasonable (contrived for this message, but reasonable) use which
relies on documented evaluation order, and would woefully break (or
possibly not, as postincrement already returns a copy not a lvalue)


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:

> The issue here is what order (if any) does perl guarantee sub-expressions
> to be evaluated? For example in
>
>     ($a+$b) * ($c+$d)
>
> does perl guarantee that the first addition will take place before the
> second addition? I think the answer is no, although I'm willing to be
> proved wrong. If not, then multiconcat has only changed undefined
> behaviour.
>
> --
> Diplomacy is telling someone to go to hell in such a way that they'll
> look forward to the trip
>


-- 
"At this point, given the limited available data, certainty about only a
very small number of things can be achieved." -- Plato, and others

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About