Thanks for attempting to answer my questions.

However, I still see some outstanding issues.

1. Tied variables.

   Any tied variable used twice in a single expression could have sideeffects.

   As the user of a variable returned by a library call, I have no idea whether the value I am manipulating is tied or not.

   If it is tied, it could have dependancy issues.

   That means that the only way for me to avoid the possibility of EOD, is to never use the same variable twice in a single expression.

   Even something as innocent as:

   my( $x, $y ) = ( $a, $a );
   [download]

   can produce totally different results depending upon the order execution if $a is a tied variable.

2. Object references.

   Using an object reference twice in the same expression could involve EOD.

   Again, with EO undefined, the only recourse for teh programmer is to never use an object reference twice in a single expression.

   Again, a silly simple example:

   my( $x, $y ) = ( $o->next, $o->next );
   [download]

   Should I have to code that as:

   my $x = $o->next;
   my $y = $o->next;
   [download]

   to ensure I get the effect I want?

3. Closures.

   A library function may use closures. Calling the function twice in the same expression could involve EODs.

   Again, the only answer to guarentee that the function will be called in the correct order, is to call it once per expression.

   And the same silly example:

   my( $x, $y ) = ( func(), func() );
   [download]

   It doesn't matter what func()> does, if there is no guarentee that the two calls to it will be executed in some order, I cannot know what the outcome of that expression will be.

All three of the restrictions make a mockery of Perl's best feature--that it is a Very High Level Language that allows me to do a lot in each line or statement.

It means that without diving into the guts of every function, object and module that I use to discover exactly how the code is implemented, I can never use two occurances of a single variable in a single expression. One line will have to exactly one, very low level step and one step only. I might as well write in assembler.

But the really, really gaulling thing about this, that I've pointed out over and over, and the other anonymonk has chosen to completely ignore, is that the very same set of reasons above, that impose such a burden on writing code that codes a single high-level, algorithmic step per line, are the very same reasons that the Perl cannot possibly derive the slightest efficiency benefit from undefinedness of EO.

So, arguing about whether it is possible to avoid EOD expressions becomes a complete waste of time, when you realise that there is no good reason not to define an execution order.

• It isn't hard to do.
• It doesn't prevent any efficiency gains.

But if it were defined, it would allow Perl to realise it's potential as a VHLL even further. I believe this to be true for Perl 5, but I realise that it is much too late for that now.

But for Perl 6, the possibility not only exists, with real benefits for the programmer as an outcome, I believe, as far as I understand Perl 6, that it almost becomes a necessity. Once you consider the potential pifalls of undefined EO when combined with things like hyperoperators, junctions, on-the-fly roles, the ability to create temporary, single instance new classes whose lives extend for a single expression only and that's before you even begin to consider the possibilities that got me interested in the first place, namely threading.

It simply isn't enough to say "Don't write expressions that could have EODs", because already, it is near impossible to know when even a single, apparently non-lvalue expression could involve sideeffects. And that is even more true of the very complex syntax that will come with Perl 6.