Re: Why is the execution order of subexpressions undefined?

As others have explained, this is evaluated left to right, but <coed>$i</code> is passed by reference. You can try something like

sub copy { my @t = @_ };
my $rv = func( copy($i), copy(++i), copy($i+2) );
[download]

or just

my $rv = func( 0 + $i, 0 + ++i, $i + 2);
[download]

(This one's tricked me too once, until the monks was kind enough to explain it in the cb.)

In fact, perl evaluates most operators from left to right, and surely always evaluates comma from left to right (whether in scalar or list context), even if this is undocumented. There can still be exceptions, for example an assigment is evaluated rhs first.

While execution order is undocumented in perl, you can count much more on it then in languages where it is actually undefined (liek scheme or C or C++), because there's only one perl interpreter and it's not likely to change much.

There is a certain amount of relegious war between fixed and undefined evaluation order. The arguments are like this. Some say that undefined evaluation order is better because it can be optimized better. Others say that this is non-sense, since the compiler can often determine that simple sub-expressions don't have side effects, and thus evaluate them in a different order anyway; and when the subexpression do have side effects, undefined evaluation order can cause confusion and misterious bugs. There's a point in both arguments, and I'm not sure which one I support.

Comment on Re: Why is the execution order of subexpressions undefined? Select or Download Code

Replies are listed 'Best First'.

Re^2: Why is the execution order of subexpressions undefined?
by BrowserUk (Patriarch) on Apr 12, 2005 at 12:41 UTC

Thanks ambrus. You summed up the situation exactly.

It was actually really hard to remember a situation where the evaluation order affected the outcome of the statement. I've been bitten by it a couple of times over the years. I've taken part in a couple of threads where it was the cause of a problem or otherwise the subject of discussion.

It means that each time I write any kind of a compound statement, or when I look over someone elses code here, looking for the source of their problem, I have to stop, look and think hard about whether there is some kind of evaluation order dependancy involved. Often, I will break compound statements into two parts, frequently needing to add a temporary variable, just so I can try it, to see if it makes any difference. Mostly it doesn't, but I'm sure it did once a long while ago.

And that's the point. Perl allows, and even encourages the use of compound statements. Like 'em or hate 'em, Perl allows them and they do have utility.

Sometimes they can clarify. Or simplify. Or reduce the chance of errors by making it harder for a single compound action to be interspersed accidently. Sometimes they produce an elegant solution (I wish I could find the discussion from around 3 years ago where Abigail-II demonstrated his triple assignment trick!?).

But as is, with the nebulous existance of the possibility of an evaluation order dependancy, using compound statements always leaves a doubt in my mind, and one which I find extremely hard to erase through knowledge or practice.

I think that given the rarity with which Perl code could actually benefit in any meaningful way from the possibility of the optimisations that an undefined evaluation order affords, I'd prefer that the loophole was quashed and my doubts eradicated.

This is one Perl 5 ambiguity that could and should be closed.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco.

Rule 1 has a caveat! -- Who broke the cabal?

[reply]


Perl Monk, Perl Meditation
	PerlMonks