Consider control structures such as for loops. In Fortran, they put the "for" after the statement to indicate vector hardware usage. Perl has the same syntax! But, it works the same as the ordinary form. But, in general the idea is to define looping constructs that are more like SIMD rather than traditional loops. That is, perform this step on each of all these items, but in no particular order. Order of the iterations is not defined, and may just as well be parallel or code for the SIMD instructions on the CPU.

In particular, the "hyper" operator syntax is defined this way. @c = @a »+« @b; will add the corresponding elements in parallel. @list.».run(); will execute the method on every item in the list, in parallel.

Also, lists may be "lazy", and establish co-routines to delay evaluation. But, if there are more cores free, why not start working on the list AND return at the same time? Don't wait for items to be needed for sure, any more than always computing them up front. It can compute the list in the background.

—John

All of this sounds great. And by great, I mean: brilliant; fantastic; amazing; extraordinary; just what the doctor ordered. I intend no hint of 'faint praise' here. But...

Does any of this actually work? Anywhere?

Each time a new parrot comes out I dutifully download it and go in exploration of the infrastructure to support these constructs, and I come up short.

And every now and again I pop over to PDD 25 and look for changes, but rarely notice any. It still talks the talk of supporting every concurrency model known to man, and then some, but comes up way short of explaining how it's going to achieve this feat.

And that's essentially why I stopped following the P6 lists. There is an aweful lot of talk about what P6 will do. Discussion after excruciating discussion about almost irrelevant minutia of what perl 6 will do. But almost nothing, and fiery defence for there being nothing, when the question is asked: how will P6/Parrot pull this off. (Not to mention the now sad joke of "by Christmas" for the question: when.)

I want to believe. I really, really want to believe...

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Actually audreyt did present a version of pugs once that parallelized meta operators, with measurable speed difference between single core and dual core (not quite a factor of 2, but somewhere around 1.7 iirc). I don't know if "mainstream" pugs does it, though.

I agree that it's hard to keep faith, but recently something helped me a lot: I played with grammars in Rakudo, and found that 1) although they are still limited, they work quite well and 2) it's really easy to parse stuff for which you'd normally write a recursive descending parser. (And I'll blog about it later this week). Now I firmly believe that they will be one of the killer features of Perl 6, even if concurrency might turn out not to work as well as promised.

I don't think that you'll see a working, usable Perl 6 level concurrency implementation within the next year, though.

It still talks the talk of supporting every concurrency model known to man

And does it really need to? In the first release?

Wouldn't it be better to keep it in mind so the design isn't completely closed to future concurrency changes, and get something out the door?

I'm assuming not everything in Perl 6 can work perfectly in the first ever release, so there would be a scoped delivery plan for which features go in 6.0, 6.1, 6.2 ... anyway, wouldn't it?

/J

Another typical example for un-ordered evaluation are junctions.

all($x, $y, $z) > 0
[download]

autothreads to

all($x > 0, $y > 0, $z > 0)
[download]

At the same time it short circuiting, so as soon as one of these conditions is false, the execution of all other autothreaded comparisons (or in general sub calls) can be interrupted.

Parallelism is one of the reasons why F90 introduced array operations, e.g., something like Perl's @a = @b or grep; implementation of these would be an obvious part a parallel version of Perl (∀Perl?). In F90, there is no special syntax akin to @a = @b »+« @c needed; it's not distinguished from a regular addition.

---

Information about American English usage here and here. Floating point issues? Please read this before posting. — emc

Consider multiplication. @a »*« @b is explicitly element-wise looping over the operator. @a * @b is not built-in, and could be defined, for example, between two Matrix objects if you like, to do matrix multiplication. You could also define infix:<+> between two lists to simply call the hyperoperator. Also, the syntax generalizes more than the implicit way of Fortran: apply a method call to each element, rather than to the container itself.