Larry wrote:
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. The natural
processing of lists says that serial is specified like this:
for @a, @b, @c -> $x, $y, $z { ... }
Of course, parallel() is a rotten thing to have to say unless you're
into readability. So we could still have some kind of parallizing
supercomma, mabye even ∥ (U+2225 PARALLEL TO).
I'd rather we not use that. I found it surprisingly hard to
distinguish∥from ||. May I suggest that this might be the opportunity
to deploy ¦ (i.e. E<brvbar>).
But let's keep it
out of the signature, I think. In other words, if something like
for @x ∥ @y ∥ @z -> $x, $y, $z { ... }
is to work, then
@result = @x ∥ @y ∥ @z;
has to interleave @x, @y, and @z. It's not special to the C<for>.
Very nice. The n-ary "zip" operator.
I suppose it could be argued that ∥ is really spelled »,« or some such.
However,
@result = @x »,« @y »,« @z;
just doesn't read quite as well for some reason.
Agreed.
A slightly better case could be made for
@result = @x `|| @y `|| @z;
Except by those who suffer FIABCB (font-induced apostrophe/backtick
character blindness).
The reason we originally munged with the signature was so that we
could do weird things with differing numbers of streams on the left
and the right. But if you really want a way to take 3 from @x, then
3 from @y, then 3 from @z, there should be something equivalent to:
for round_robin_by_3s(@x, @y, @z) -> $x, $y, $z { ... }
Or perhaps just:
sub take(int $n, *@from) {
yield splice @from, 0, $n while @from > $n;
return ( @from, undef xx ($n-@from) )
}
&three = &take.assuming(n=>3);
for three(@x), three(@y), three($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 reinstituted the previous exception that a semicolon in an parameter
list marks the start of optional parameters! :-)
Damian
