Moritz Lenz wrote:
You can achieve that with the "hyper" list-op (see S02). Also note that an optimizer is free to automatically add the "hyper" list op if it can prove that the executed block has no side effects.
Yes, there are some places where things are better than others, which is why I called out S04 specifically. The concern I have is that it is necessary to use a "functional" subset to explicitly tell Perl6 that I want it to do the right thing on many-core systems.
The bias that I see is the perceived need to say that hypers (and junctions) may "auto-thread", without needing to be explicit that control statements "auto-sequentialize". That latter is assumed, but the former is explicit: this asymmetry is the bias.
In as much as it is possible to talk about core features for Perl6, the control structures of S04 are "core". Given generic iteration and selection mechanisms that are unbiased with respect to concurrency, it is moderately straight forward to define the sequentially constrained versions as an "add on" feature. The reverse is more difficult: concurrency as an add-on feature is hard.
That sounds really like a bad idea for simple "just do it" scripts. Just imagine explaining concurrency issue to a beginner who is not even confident with variables and blocks...
Just like hyper-operators, the form of the statements that are less biased towards sequentialization need not be dangerous for beginners, if the language design is careful.
One could start simply by defining the order of iteration to be undefined, and adding a form that does guarantee the order for those cases where it does matter. From there, it is a fairly small jump from "unordered" to "concurrent", assuming the bulk of the language has semantics that preserve safety for concurrent operations (admittedly, a non-trivial assumption).
