Larry Wall wrote:
> I (impersonally) believe that hyper context is the right solution to
> this because context can propagate to where it needs to dynamically.
> As for the fact that it's not the default list context for "for",
> that could easily be changed with a pragma. Maybe that could even
> be the default someday, but we have to educate people to think about
> "hyper" first.
As I just indicated, I'm a mere mortal; so some of the terminology
you're using here is throwing me. When I hear "hyper context", my gut
instinct is to think "he's advocating some sort of application of the
hyperoperator". Is that what you mean, or would the substitution of a
bag for a list in a "for" statement qualify as "hyper context"?
Or maybe you mean something like the use of a junction in a "given"
statement as the parallelized equivalent of a "for" statement?
for @x { ... } # executes the block for each element of @x in series
given all(@x) { ... } # executes the block for each element of @x in parallel
> As for the other part of the proposal, a parallel smartmatch would
> need new comb syntax for the compound pattern--I wouldn't overload
> given/when for that. Or maybe just make a way to attach a mapreduce
> action to any leg of a junction or hyperoperator.
Again, I'm not up on the terminology being used here. But if I'm
getting the gist of it right, the following is in the spirit of what
you're suggesting:
Introduce a function that does given/when-type smart-matching, but
geared around pattern/code Pairs: e.g.,
match $x: 1..3 => { dothis() }, 4..6 => { dothat() }
# equivalent to:
given $x {
when 1..3 { dothis() }
when 4..6 { dothat() }
}
Then you could use a junction of Pairs in place of a single Pair to
smart-match the patterns in parallel:
match $x: 1..3 => { dothis() } & 2..4 => { dothat() }
# smart-matches 1..3 and 2..4 in parallel
> In any case, we need
> to make sure it's easy to place such a parallel comb of matchers at the
> pointy end of a feed, and if the source of the feed is also executing
> in parallel, make sure the feed can be optimized to a full crossbar
> based on packet destination.
In the above example, you might say:
@x».match 1..3 => { dothis() } & 2..4 => { dothat() }
or
match any(@x): 1..3 => { dothis() } & 2..4 => { dothat() }
in order to get a full crossbar.
> It's also possible that we should discourage syntactic parallel
> matching in favor of parallel polymorphic dispatch, given that
> signatures can also express patterns. Might need to tweak the current
> multiple dispatch rules a bit though if we want dispatch ambiguity
> to express nondeterminism. In any case, real mapreduce situations
> are often generated dynamically, and cannot easily be expressed in
> a syntactically fixed set of options.
No idea what you're talking about here.
--
Jonathan "Dataweaver" Lang
