Larry Wall <> writes:
> But at the moment I'm thinking there's something wrong about any
> approach that requires a special character on the signature side.
> I'm starting to think that all the convolving should be specified
> on the left. So in this:
>
> for parallel(@x, @y, @z) -> $x, $y, $z { ... }
>
> the signature specifies that we are expecting 3 scalars to the sub,
> and conveys no information as to whether they are generated in parallel
> or serially. That's entirely specified on the left.
if I understand correctly, the main problems with Apocalypse version
of "for" are :
* need for special meaning of ";" in the nlock signature
* need to specify unifying/intersection/other behaviour
* not everybody is happy with strean vs block arguments alignment
possibilities
one solution , to which thetread converged (??) is to essentially give
simple ways to "weave" many streams in single one, and "for" to become
always "single-stream" . this is essentially the old @a ^| @b proposal
written in english. it doesnot solve the "alignment" problem. also ,
it seems ( but may be I am wrong ) that there is run-time overhead ,
since "weaving" if done explicitly takes additional time ~ length of
arrays . this will not happen if "for" will notice one of "weaving"
functions and optimize it away. So that means that we will have to
have "standart" set of "weaving" functions recognizable by "for" .
so possibly we can revive the multistream for if we wrap this
behaviour around "loop" and "given" , something like this
loop {
given each @a -> $x {
given each @b -> $y {
given each @c -> $z {
last loop if undef $x|$y|$z
....
}}}}
this is already valid perl6 syntax if array @a have iterator method
similar hash. ( may be it is called @a.next or @a.iter ) .
and if "each" will notice how many arguments closure expects.
as it is , it looks weird , and we loose the fact that "for" loop is
*single* topicalizer scope ( here we have to break 3 of them to get
out . and also the topic inside the ... is the *last* argument $z and
not the first as would be for "usual" for .
so strictly speaking , this is not "wrapping around" -- this is just
valid (??) sintax. but may be it *is* possible to somehow wrap the
multistream behaviour around loop - given pair.
I dont know. maybe new keyword "stream"
loop {
stream @a -> $x,$y {
stream @b -> $z {
stream @c -> $alpha,$beta {
last loop if undef $x|$y|$z
....
}}}}
and "stream" does not set the topicilizer scope. it seems that
"stream" is just a function . and then it does not automatically
create a topicalizer scope.
or maybe "each" is sort of redundant inside given and we have
loop {
given @a -> [$x,$y ] {
given @b -> [$z ] {
given @c -> [$alpha,$beta] {
last loop if undef $x|$y|$z
....
}}}}
but then @a will have to remember its current index.
and given to be aware of it. may be its too much for given.
>
> for round_robin_by_3s(@x, @y, @z) -> $x, $y, $z { ... }
>
> Fooling around with signature syntax for that rare case is not worth it.
> This way, the C<for> won't have to know anything about the signature other
> than that it expects 3 scalar arguments. And Simon will be happ(y|ier)
> that we've removed an exception.
>
and for this type of things there is always "weaving" possibility.
arcadi .
