Perl does have a defined order of evaluation;
Do you know something that neither p5p nor comp.lang.perl.misc
knows? Order of evaluation has been discussed recently on both
forums, and noone one these forums has been able to show that
Perl has a defined order of evaluation. Please quote the relevant parts of the documentation that define order of evaluation in general. (Order of evaluation is defined for
&&, ||, and, or and comma in scalar context, but not
generally).
How can I trust
print 5+1;
always prints 6, and not 5 (and a warning)?
Precedence garantees that. Just like C, Perl does have
well defined precedence and associativity rules. But neither
language has a defined order of evaluation.
Abigail
| [reply] [Watch: Dir/Any] [d/l] |
This one thing amazes me. ML is functional (though not purely), side-effects are pretty rare there, yet it does specify the order of evaluation in all cases. C and Perl are full of side-effects, yet they don't.
Jenda
Always code as if the guy who ends up maintaining your code
will be a violent psychopath who knows where you live.
-- Rick Osborne
Edit by castaway: Closed small tag in signature
| [reply] [Watch: Dir/Any] |
Not defining order of evaluation leaves more possibilities
open for optimalizations. Consider for instance the
expression:
f ($a) + g ($a)
If you define an order of evaluation, it would probably
be:
- fetch the value of $a
- call f() with $a as argument, remember the return value
- fetch the value of $a
- call g() with $a as argument, remember the return value
- add the return values of f() and g().
Notice the twice fetching of $a. If the order of evaluation
isn't defined, you can first fetch the value of $a twice.
Even if you do fetch the value twice (instead of fetching
it once and remembering the results), doing it before calling
f() and g() could be a win due to an increased chance of
cache hits. It will also give you the opportunity to evaluate
sub expressions in parallel.
Last but not least, if the order of evaluation is defined,
people will start writing code that depends on this. This
will lead to fragile code, that will break if you swap the
arguments of an otherwise symmetric operator.
Finally, I don't see how lazy evaluation and a defined order
of evaluation combine to a happy programming language.
Perl6 will have a defined order of evaluation, and have
lazy evaluation. I wonder how Larry is going to pull off
that one.
Abigail
| [reply] [Watch: Dir/Any] [d/l] |