Whilst the evaluation order is undefined
The behaviour is even definable and consistant
Those two lines contradict each other.
perl -MO=Deparse,-p only shows you
precedenceorder, not evaluation order.
Take for instance
$a = $a ++ + $a ++;
The evaluation order might be:
- Fetch the value of $a, save a copy. (A)
- Increment the value and store it back in $a.
- Fetch the value of $a, save a copy. (B)
- Increment the value and store it back in $a.
- Add (A) and (B), store the value in $a.
But it also might be:
- Fetch the value of $a (A)
- Fetch the value of $a (B)
- Add (A) and (B), store the value in $a
- Increment (A), store it back in $a
- Increment (B), store it back in $b
The order of evaluation is UNDEFINED,
and therefore, the entire statement is has undefined
behaviour.
And yes, I know the argument, "If I run the program, it
always returns XXX". That doesn't say anything. The order
in which keys are returned from a hash is undefined as well.
If you write a program that inserts the numbers 1 to 100
in a hash, in that order, and then fetches the keys, you
will get the same order on each run of the program. Does
that mean the order is defined? No, because that fixed order
will no longer happen with 5.8.1. Then the order will differ
from run to run. And it's safe to introduce that in a
maintainance release, because the order in which keys are
returned is undefined, even if you think you can predict it.
Abigail | [reply]
[d/l] |
$a + $b
is that both sides will be evaluated before
the addition.
What is not defined is whether $a or
$b will be evaluated first.
In my example it doesn't matter, but if both
terms use and alter the same
variables then there can be side effects
between the terms.
| [reply]
[d/l]
[select] |
Abigail, I think you misspoke. You are indicating that the addition may precede the increments in your second
choice.
Indeed. That may happen. Post increment
means that the variable will be incremented some time between
fetching the old value and the end of the statement. It doesn't
say it will be incremented before the evaluation of some
other operation in the same statement.
Your earlier statement that behaviour is "undefined" is also incorrect.
If my statement is incorrect, it must mean that the behaviour
is defined. Please define that behaviour for me, quoting
the relevant parts of the documentation.
In my example it doesn't matter, but if both terms use and alter the same variables then there can be side effects
between the terms.
Exactly. Hence, undefined behaviour.
Abigail
| [reply] |
Your right Abigail.
In the scheme of how future perl releases will behave, it is undefined. and is therefore unpredictable. I wasn't disagreeing with this.
In terms of how any given installation of perl behaves now, then Deparse can illuminate the order in which things are evaluated. And if you inspect a few similar sets of Deparse outputs it becomes predictable how other similar expressions wil be evaluated for that given installation.
This doesn't remove the risks associated with relying upon the current behaviour, and was not meant to encourage such reliance. Only to explain that behavour and show that it isn't random. Just unwritten and subject to change.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.
| [reply] |
