in reply to
Re^2: RFC: Implicit Parallelization Pragma
in thread RFC: Implicit Parallelization Pragma
That's the main reason Perl 6 has hyperoperators, and to a lesser extent the junctional operators. A pragma simply isn't specific enough. In the case of hyperoperators and junctions, we've said that it's erroneous to depend on any order of evaluation, which is a slightly weaker constraint than requiring no side effects. There can be side effects,
as long as each element's side effects are independent of the other elements. Actually, even that's slightly overstated--the effects just need to be idempotent. Each branch could independently do $counter++ and it doesn't matter what order they happen in, at least for hyperops.
The main practical difference between hyperops and junctions in this regard is that hyperops are guaranteed to run to completion, whereas junctions can short circuit whenever they jolly well please and in any order. So I guess the effective constraints on junctional operators are a bit tighter than on hyperops. Generally speaking junctional operators should have no side effects, because you won't know how many of them will happen.
The autothreading of array indices in S9 is also intended to allow parallel execution where possible. The trend toward vector-capable processors has been evident for some time now, and we want Perl 6 to map naturally to those. Even if the Cell architecture doesn't take off, we all have rather powerful GPUs in our machines these days...