But that's the whole reason evaluation order doesn't matter in Erlang.

As I already pointed to the other anonymonk, I did not mention Erlang in that context. Only as a (preferable) altenative to Haskell, especially with regard to it's treatment of concurrency, so stop stating the obvious.

And lack of that feature in Perl is exaclty the cause of all your problems.

I don't have any problems. I never did. Read the title of the thread, I simply asked why.

And so far, noone has offered a single good reason why EO should not be defined in Perl, nor countered my assertion that Perl does not benefit from it's being undefined in terms of efficiency, which is the only reason so far offered.

I would disagree. The ability to parallelise in perl6 is an awesome reason to leave EO undefined. Defining EO necessarily serialises statements, which would prevent future perl interpreters from automatically threading inside single, complex statements, and thus gaining huge amounts of efficiency on multi-processor systems.

This is more than a good reason, and has been offered.

Perl, as it is today, probably does not benefit from undefined EO. Perl as it may be in the future, would be hamstrung by an attempt today to define EO, as we would not be able to offer backwards compatability. True, perl6 does not offer backwards compatability with perl5. But who says perl 5.12 won't finally have a working, stable threading system built-in, and be able to use it?

Would you agree that Perl could only implicitly parallelise functions, methods or tied variables if they appear in the same statement?

If the programmer places them on separate lines, he is implying serialisation.

Let's get abstract. In the following code, func1() and func2() return results obtained from slow external resources that lend themselves to automated threading. Think overlapped IO for example.

For the sake of contrivance, and as we are being abstract, we'll assume that func2() requires a 1 based index (think lines or bytes in a file) and func1() requires a zero based index (arrays). Now, if EO is undefined, the following line will not work as required because the compiler is free to evaluate the value of the function parameters in any order and the programmer can do nothing to control them.

    $result = func1( $var++ ) op func2( $var );
[download]

However, if he codes that as

    $temp1 = func1( $var++ );
    $temp2 = func2( $var );
    $results = $temp1 op $temp2;
[download]

or

    $temp1 = func1( $var );
    $temp2 = func2( ++$var );
    $result = $temp1 op $temp2;
[download]

besides the extra variables and statements required, the opportunity for overlapping the processing in func1() and func2() is lost because their invokations are now implicitly serialised by the statement ordering.

Your earlier contention was that by having the EO undefined, the compiler can decide to run the code in parallel, but it cannot, because it has no way of knowing, and the programmer has no way of indicating, that the two routines do not have interdependacies.

But if EO is defined, then by putting the two function calls in the same statement, and ordering them the way they are

    $result = func1( $var++ ) op func2( $var );
[download]

the programmer is explicitly stating that they do not have interdependancies and *can* be run in parallel.

If he doesn't want them to be run in parallel, he has the choice of placing them in serial statements, and they will not be.

He can also depend upon each function receiving the correct parameters because the subexpressions from which those parameters are derived must be evaluated first, and in the order specified. The point of synchronisation is 'op', whatever that may be. At every stage, the programmer can control what happens, in what order, instructing the compiler what to do and when and also freeing the compiler to parallelise the fetching of the operands if it has that capability.

No extra syntax is involved. Just a clear definition that allows the programmer to instruct the compiler, rather having to guess what it might do.

---

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?

And so far, noone has offered a single good reason why EO should not be defined in Perl

It is bad form to code like you want to. Just like goto. It makes the code ugly and hard to understand. But of course this point has been made a number of times already, you just choose to ignore it.

Hey. If goto is bad, why is it in the language?

It is rarely used, but it is there for those occasions when it is necessary, or easier or clearer.

---

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?