Larry Wall wrote:
It's really, really easy to misdesign a computer language by overemphasizing one particular design dimension to the detriment of others.
I agree that adding a parallel "forall" (and similar statements) via a pragma will be easy if the appropriate underlying machinery is there, so maybe I can live with the bias in S04 -- perhaps rename it to "Sequential Blocks and Statements". Anywhere that we guarantee sequential behavior, we pretty much rule out concurrency. But if we maximize the number of places where we are explicitly "unordered" then we also maximize the number of places where implicit concurrency can be added later. From that perspective, it's unfortunate a C<for> loop always iterates arrays in the order of their indices.
As I see it, parallelism is easy: it's synchronization that's hard. Specifically, it's hard to get exactly the right scoping of constraints. And it seems to me that "hyper" addresses the parallelization aspect but not synchronization. Concurrency.pod (S17) defines a few basic mechanisms, but it's not obvious that they're really "easy", or sufficiently declarative. There seem to be synchronization scopes analogous to "state" and to hypotheticals, but not "my", "our", "temp", and "has". (I'm not sure exactly what primitives are needed: we could discover that by doing more parallel programming ... which won't happen unless it's easy)
The way humans seem to work is that they'll say "I'll do this and this separately, but I won't worry about that unless something goes wrong". We employ a mixture of course grain threading, fine grain locking, exceptions, and recoverable transactions; that we juggle dynamically. That's pretty hard to do when writing a program, which is why I want to place the burden on the language designer, not the language user.
With Perl 6 we're trying to make the opposite mistake.
I fear you may be successfully underemphasizing one dimension to the detriment of others :-). But considering that you do a pretty good job most of the time, I'm not too worried.
