I was reading Synopsis 4 with regards to multi core programming. It
seems to be infused with a bias towards non-parallel models of
computation. Concurrently appears to be an add-on feature -- whereas we
should have a mindset that explicit sequential constraints are the
add-on feature.
Two statements that are missing from S04 (feel free to change the names)
are C<forall>; and a form of C<given> that tests/executes multiple
C<when> clauses in arbitrary order (without needing the sequential
C<continue> statement).
forall @a -> $x { ... }
runs the code block on each element of @a (no defined order). If @a is a
lazy generator then generation of values is concurrent with running the
code block on those generated values).
forall @a -> $x : sequential { ... }
forces an additional sequential constraint on the execution, such that
the Nth element of @a is not obtained until the code block has executed
for the (N-1)th. C<for> is an alias for this constrained variant. C<for>
implies this sequential constraint to avoid surprising legacy (perl5)
programmers.
Similarly, C<map>, C<classify>, C<grep>, C<reduce>, ... should all
accept this ":sequential" adverb to force them to iterate their lists
sequentially -- and should otherwise iterate in arbitrary/concurrent order.
given $x :all { ... }
would run the code blocks of all C<when> statements (in the C<given>
block) which smart-match true against $x. The ":sequential" adverb would
be used to constrain execution of the C<when> blocks to run in the order
they appear in the source code. (it would be good if the current
C<given> could be thought of as using a ":first" modifier, which runs
the code block of the lexically first C<when> clause that evaluates to
true -- but which potentially tests multiple C<when> clauses in
parallel. Unfortunately the current language definition is much too
sequential for this viewpoint)
I'm not too concerned about the exact details: my point is that we
should be fully aware of the fact that perl6 will be released into a
multicore (some people use the term many-core for devices with hundreds
of cores) world, and that exploitation of these parallel resources
should be the default (easy) behavior. We shouldn't have a "concurrency"
synopsis (we don't -- but we do have Spec/concurrency.pod). Instead, we
should have "sequential.pod" that defines how to impose additional
sequential constraints (e.g. ":atomic", ":sequential") on top of the
those inferred from data dependencies.
Even "threads" should actually be viewed as an explicit sequential
construct, and not as a construct for parallelization. The default
(easy) way of coding should exploit the available compute resources.
Telling the execution engine how to map the computation onto N
sequential resources is a constraint (optimization) that reduces
parallelism.
I'm not asking anyone to implement any concurrency beyond what is
currently planned for perl 6.0.0: I ask only for the language definition
to avoid making unnecessary guarantees of sequential behavior.
"sequential" is a perfectly reasonably interpretation of
"arbitrary/concurrent" ordering.
I'd be happy to go through and scrub the docs, if there was consensus
that it would be correct to do so. Unfortunately, doing so would
probably increase the future brittleness of the test suite -- because
existing tests may assume sequential behaviors, and it's difficult to
test for robustness against arbitrary ordering without actually
implementing arbitrary ordering.
Dave.
