Matthew Walton wrote:
I wouldn't agree with that at all. I think of arrays as ordered constructs, so I'd want the default iteration over my array to happen in the order of the indices.
I guess that depends on whether you think of the array as a list or as a ram. I know that a group at microsoft added a ParallelArray datatype (ftp://ftp.research.microsoft.com/pub/tr/TR-2005-184.pdf) to C# as a way to distinguish the intent (they speed up data-parallel code by compiling it down to your GPU/graphics card). Perl6, being an operator-oriented language, associates the distinction with the operators rather than with the datatype. This is probably a better approach, but it does mean that you need an operator whenever you want to treat the array as data-parallel. (BTW, data-parallel arrays differ from bags in that they have an ordered index that is preserved across unordered operations)
I think you're leaning too far towards concurrency in attempting to address the perceived bias.
Probably true ... though I think that the bias is real, it's just a question of if its a good-bias or a bad-bias.
Under these circumstances, I would much rather have to explicitly say that I want parallel execution - provided that the ability to do it is there and it's easy to get at and behaves in a sensible manner (naturally this lets you parallelise things the compiler isn't sure are safe to parallelise due to possible side effects. That's fine, since you know which side effects are okay to do that to in your program).
Of course, it's not necessarily true that "you know" that something is safe -- often "you think" it's safe but then you get an intermittent failure at runtime,. I would love to be able to tell the compiler "I think this is safe" and have it tell me "you're wrong" as a compile-time error (this is one of the things that an explicit type system is good for). But perhaps Perl is too dynamic a language for that.
