here's no guessing involved if you are going to write an expression that doesn't depend on the order of evaluation. Guessing is required if you write an expression that does, and you don't know the order because it's either not defined, or you can't memorize the table.

What makes this meaningless is this. (EOD==Evaluation Order Dependancy)

You say "...there's no guessing involved if you are going to write an expression that doesn't depend on the order of evaluation."

Noone sets out to write a expression that has EOD--they simply write an expression. The problem is that you have (repeatedly) refused to give a comprehensive list of what consitutes 'an expression with an EOD'.

So, that leaves everyone, having written their expression, in the situation of having to guess whether it contains an EOD or not.

That's guesswork!

You have been attempting to imply that you always know when a statement would have EODs, and would therefore avoid them by breaking that statement into two or more parts and utilising temporary variables. I am calling you on that implication and asking you to demonstrate your superiour knowledge by showing me, and everyone else all the situations in which an EOD can arise in Perl.

1. For the purposes of this subthread, you may contain your reply to just those that can occur in Perl 5 and single-threaded Perl.
2. However, ultimately, for the purposes of the overall thread, you should consider elaborating all the situations in which an EOD could occur in Perl 6, with it's autothreading, multimethod dispatch and junctions and threading also.

I know you will not attempt to satisfy even the extremely restricted set of abiguities possible in scenario 1 above, never mind tackle the much harder, wider implications of scenario 2.

You won't attempt the former because it will show your superior knowledge to be nothing more than a superiour attitude, and reenforce my statement that your rhetoric is hollow and therefore meaningless.

I know you won't attempt the latter, because you haven't even considered that scenario--it being beyond your chosen limits.

I have considered it. And it is my conclusion that the abiguities that arise out of institutionally declining to define the execution order of expressions, when considered in the world of Perl 6, with all it's additional possibilities, will create the a situation where the Perl 6 programmer will be constantly second guessing what the compiler will do. I suggest that that is untenable and should be addressed and resolved.

I further claim that the benefits that could possibly arise--a few, very rare occasions when the compiler could use the lack of defined execution order to achieve an extremely marginal improvement in efficiency--are so rare and small that the downside in terms of extra effort on behalf of the programmer in guessing whether the expression he just wrote contains an EOD, and then breaking up that expression and adding temporary variables, far, far outweights any possible benefits.

I also contend that last statement is true for Perl 5. I challenge you to show some demonstrable gain that a piece of Perl (5) code can derive because the execution order of expressions is undefined?

Again, You probably will not even attempt this, because you know that you will not be able to show any real benefit.

You really should try arguing the subject instead of the man.