Scott Duff wrote:
Very nice. The n-ary "zip" operator.
Um ... could we have a zip functor as well?
Yes, I expect so. Much as C<|>, C<&>, and C<^> will be operator versions
of C<any>, C<all>, and C<one>.
And I'd suggest that it be implemented something like:
sub zip(ARRAY *@sources; $by = 1) {
if exists $by && all(@sources).isa(PAIR) {
warn "Useless 'by' argument (every array already has a count)";
}
else {
for @sources { $_ = $_=>$by unless .isa(PAIR) }
}
my @zipped;
while any(@sources).key {
push @zipped, splice(.key, 0, .value) for @sources;
}
return @zipped;
}
> So, in the spirit of timtowtdi:
for zip(@a,@b,@c) -> $x,$y,$z { ... } # one at a time
for zip(@a,@b,@c,3) -> $x,$y,$z { ... } # three at a time
As implied above, I think the N-at-a-time behaviour would be better
mediated by an optional named parameter. So that second one should be:
for zip(@a,@b,@c,by=>3) -> $x,$y,$z { ... } # three at a time
Or if we generalized zip() a little:
for weave(@a,2,@b,1) -> $x,$y,$z { ... }
Which would take 2 elements from @a, and one from @b, until both
arrays were exhausted.
As Buddha Buck suggested elsewhere, and as I have coded above,
I would imagine that this functionality would be mediated by pairs
and merged into a single C<zip> function. So that last example is just:
for zip(@a=>2,@b=>1) -> $x,$y,$z { ... }
Damian
