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.