Perl somehow knows what the execution order should be!
$ perl -MO=Concise,-exec -e'sub func {@_} my $rv = func( $i, ++$i, $i+ +2 )' 1 <0> enter 2 <;> nextstate(main 2 -e:1) v 3 <0> pushmark s 4 <$> gvsv(*i) s 5 <$> gvsv(*i) s 6 <1> preinc sKM/1 7 <$> gvsv(*i) s 8 <$> const(IV 2) s 9 <2> add[t2] sKM/2 a <$> gv(*func) s b <1> entersub[t3] sKS/TARG,1 c <0> padsv[$rv:2,3] sRM*/LVINTRO d <2> sassign vKS/2 e <@> leave[1 ref] vKP/REFC -e syntax OK $
Perl does make some guarantees about execution order - they are implied by the rules of precedence and associativity in perlop. In your example, the parens around the argument list make it a TERM, the highest precedence, so the enclosed expression is evaluated first. Within that expression, the preincrement operator has highest precedence, so it is applied next. Then comes addition in the third term and finally the commas. The commas tie in precedence, so associativity comes into it and they evaluate left to right - a trivial operation in this case. I think that func acts as a list operator, so assignment is evaluated next. Being right associative, assignment evaluates func first with the arguments we already calculated, and copies the result into $rv (in scalar context).
As far as I know, Perl doesn't make the distinction between operator-comma and punctuation-comma that C and C++ do. I believe that comma is always an operator in Perl (if I'm mistaken, I expect I'll hear about it!). It seems to be only scalar vs. list context which distinguishes between the sequence operator and list seperators - giving func the ($) prototype results in the same order of operations exposed by B::Concise.
Where C's undefinedness does creep in is through the increment and decrement operators. They are "nonassoc" in the precedence table, and are explicitly documented to have undefined results when used multiple times on the same variable in a single statement. It also seems to be discouraged to evaluate the variable itself, as in your example.
Currently, Perl permits those undefined operations and does them consistently, though oddly. Such expressions turn up pretty regularly in SoPW. Their behavior can be understood by realizing that post-inc and -dec return values while pre-inc and -dec return aliases (so reflect changes from subsequent operations), and that the operators are evaluated from left to right. Again, I emphasize that Perl docs warn against relying on this.
The precedence table approach to deciphering what perl will do is not perfect. For instance, being punctuation, brackets for array indexing or referencing are not covered in the table (though they obviously have a high effective precedence). I wonder if they come in under the TERM heading?
After Compline,
Zaxo
In reply to Re: Why is the execution order of subexpressions undefined?
by Zaxo
in thread Why is the execution order of subexpressions undefined?
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |