Whilst the order maybe unspecified and potentially vary from build to build, I would expect that the same line of code to evaluate in a consistant fashion within a given build, especially within a given run.

Unless of course it is littered with :)

/* Teach them not to bracket enough {evil grin} */
switch ( int( rand()*varients ) ) {
    case 0: {...};
    case 1: {...};
    ....;
}
[download]

That's what I would expect, too, but if the order is undefined, we're not guaranteed to get what we expect.

For example, say that while a sub is running, it becomes apparent to Perl that the way it ordered things last time wasn't optimal (maybe the sub rarely uses its second argument, so evaluation of this argument should be deferred until it's actually used). Although unlikely, it would be legal to re-order anything whose order was undefined.

This is certainly bizarre behavior, and may well be a bug, but I've not seen mention of, or found, any solid documentation about whether the order of execution for these assignment and xor operators are defined or not, and if they are defined what the order is supposed to be.

I understand what you are saying, and a defined order for sub-expression and parameter evaluation would be nice, though perl is far from the only language that chooses not to specify one. The usual statement is "Don't write code that relies upon the order of such evaluations, as it may change". That said, I'm pretty sure but can't put my finger on where it is documented, that chained assignments will always evaluate right-to-left. Hence

my( $a, $b, $c ) = ( 1, 2, 3);
$a = $b = $c = 1;
print "$a$b$c";
[download]

will always result in 111. And, by extension, with simple integer terms

my($a,$b) = (23, 99);
$a ^= $b ^= $a ^= $b;
print "$a : $b";
99 : 23
[download]

will always work.

When using Lvalue subs as the terms, then it might be possible that the parameters to the left-most sub could be evaluated and stacked before those of the subs to its right, and if perl used pass-by-value, then stacking the paramaters left-right and calling the subs right left, would make a difference to the outcome. As the parameters are either passed by ref or constants, there is no side-effect possible from the order of evaluation of the parameters.

...it becomes apparent to Perl that the way it ordered things last time wasn't optimal...

Until they starting building AI into computers, or TheDamian manages to get his collapsing quantum states into perl and the Heisenberg Principle starts to bite me, I prepared to assume that, in the absence of a documented caching effect, a piece of code that does not display repeatability is a bug rather contrary intelligence! In fact, the day my computer starts reflecting my own personality back at me, I'm moving to Aus. and becoming a fly swatter. My CV says I'm good at squashing bugs:)

Please, it's humour. And in the final current analysis, the joke is probably on me.

I am beginning to suspect that this maybe another manifestation of a bug I reported about a year ago [substr] anomaly or mine? that was closed as "working as designed" (much to my personel displeasure, but how can I argue?), and maybe related to a problem I raised LVALUE refs and diotalevi reported earlier this year.

The different effect you and dws reported (ie. ' B' ), I also see if I try my original testcase on my home-built version of 5.8.1 (which has the fix diotalevi mentioned in his post). I don't use this normally as I have to cripple it to get it to build with my free compiler.

Finally, a better implementation of swab() that works under 5.8.0 and 5.8.1, uses one less call to substr, no xoring and no temporary variables, is

#! perl -slw
use strict;

sub swab {
    substr( $_[0], $_[1], 1,
        substr( $_[0], $_[2], 1,
            substr( $_[0], $_[1], 1    )
        )
    );
}

my $s = 'AB';
swab( $s, 0, 1 ), print "'$s'" for 1 .. 10;
__END__
P:\test>test
'BA'
'AB'
'BA'
'AB'
'BA'
'AB'
'BA'
'AB'
'BA'
'AB'
[download]

Note: Chaining 3 Lvalue assignments substr($,0,1) = substr($,1,1) = substr($,0,1); doesn't work. This is the inconsistancy between the value returned by the 3 arg substr used as an lvalue and the 4-arg substr that I found in the first link above and was dismissed as not being a problem.

(Late breaking thought!) Back to the order of execution thing. The Synopsis of Perlop shows that all the assignment operators are of equal precedence and right associative. It goes on to say further down under the "Assignments" heading that

Assignment operators work as in C. That is,

    $a += 2;

is equivalent to

    $a = $a + 2;

although without duplicating any side effects that dereferencing the l
+value might trigger, such as from tie(). Other assignment operators w
+ork similarly. The following are recognized:

    **=    +=    *=    &=    <<=    &&=
           -=    /=    |=    >>=    ||=
           .=    %=    ^=
                 x=

Although these are grouped by family, they all have the precedence of 
+assignment.

Unlike in C, the scalar assignment operator produces a valid lvalue. M
+odifying an assignment is equivalent to doing the assignment and then
+ modifying the variable that was assigned to. This is useful for modi
+fying a copy of something, like this:

    ($tmp = $global) =~ tr [A-Z] [a-z];
[download]

Which, to my way of reading, means that there is no ambiguity in the order of evaluation of the original implementation of swab(), but I could be wrong, I often am:)

---

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.