$c = $a + $b;
[download]

You said:

for my $i ( 1 .. $n ) {
    $results[ $i ] = $db->getLocalData() * $lwp->getRemoteData();
}
[download]

The db object and the $lwp object can both run in parallel. The EOD is on the results, not the method calls.

for my $i (1 .. $n) {
  $results[ $i ] = somefunc1($i) + somefunc2($i);
}

{
  my $data = 0;
  sub somefunc1 {
    my $i = shift;
    $i += $data++;
    sleep(1);
    $i;
  }
  sub somefunc2 {
    my $i = shift;
    sleep(1);
    $i *= $data++;
    $i;
  }
}
[download]

If, however, EO remains undefined, we place the ball firmly and explicitly in the developer's court. We are saying, "we, the compiler, make no guarantees about the order in which we evaluate expressions, or even if they are to be evaluated if we can prove their value is useless (e.g., 0 * foo(), if we know that foo returns natural numbers, as per its perl6-style prototype), or even that there will be an order if we can do it in parallel - if your code cannot handle this, it is up to you to use explicit synchronisation points (aka ";") to delineate where you want me to synchronise my calculations." Yes, you need to use temporary variables to store intermediate values. However, nothing says that this intermediate value can't be optimised away, as long as the compiler can guarantee that synchronisation point between executions, in the order that you specify.

In fact, I would love to see perl6 go the other way - and allow me to say "for this block of code, execution order is whatever you want." And then inside that, other blocks that say, "Well, treat this as sychronised." Or something like that. For example:

parallel {
  clean_up_tmp_dir();
  serial {
    $data = read_value_from_db();
    $data += read_value_from_lwp();
  };
  serial {
    my $other_stuff = fib(3) * fib(8);
    do_something($other_stuff);
  }
};
[download]

And? I didn't suggest otherwise. I mention Erlang as a counter to the monads fudge of Haskell.

---

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?

But that's the whole reason evaluation order doesn't matter in Erlang. And lack of that feature in Perl is exaclty the cause of all your problems.

That's a very interesting article. Thankyou.

I agree that explicit threading is not the way of the future. I also think that neither native threads nor "user" threads are either, individually, sufficient to make good use of future architectures. I belive a combination of the two, and transparency is required.

For why and how, please contact me via the email on my homepage.

---

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?

C:\ghc\bin>ghc -V
The Glorious Glasgow Haskell Compilation System, version 6.2.2
[download]

---

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?

So then you're going to show us a piece of code which is slower in Haskell than in Perl?

It's not a complicated or extravagant request:

Please make the language definition such that the compiler will do things in a predictable, defined sequence so that I the programmer can choose how I want them done. Even if the result is a tny weeny bit less efficient than it might be--which it never will be in Perl.

my $rv = func( $i, ++$i, $i+2 );
[download]

   # either this:
$rv = func( $i, $i+1, $i+2 );  $i++;

   # or this:
$rv = func( $i, $i+1, $i+3 );  $i++;
[download]

But the problem for me is that the initial expression, taken by itself without an external rule of interpretation, is inherently ambiguous. Whichever rule is chosen to make this statement unambiguous, it will be a relatively arbitrary choice. And I'll need to see and understand the documentation for it in order to figure out what that initial expression is really doing. (update: either that, or else I'll just have to experiment with it to see what it does)

The same issue comes up for me in cases where execution order is already well defined, like  $i*$j/$k*$l; -- sure, evaluation is simply left-to-right, and most languages are the same in this regard, so nobody should have any trouble with this. But I would still prefer to place the terms in an order that would be unambiguous regardless of the EO rules, and/or add some parens just to be sure. It's a small price to pay for clarity, given that the language is intended as much for human readers as for machines.

So my objection to your request is: why add arbitrary rules to the language, if the intent is simply to provide a consistent result for ambiguous expressions? IMHO, it would be better to be clear about what constitutes ambiguity in the language, and avoid it.