Zip more than two arrays?

[Mark Reed]

Hm. This brings up another point, which may have been addressed . . .

The Python function and Ruby array method zip() both accept any number of
arrays to interleave:

>>> zip([1,2,3],[4,5,6],[7,8,9])
[(1, 4, 7), (2, 5, 8), (3, 6, 9)]

irb(main):001:0> [1,2,3].zip([4,5,6],[7,8,9])
=> [[1, 4, 7], [2, 5, 8], [3, 6, 9]]

How would you write the above in Perl6, given that ¥/Y is an infix operator?

On 2005-10-21 5:32 PM, "Mark Reed" <mark...@turner.com> wrote:
> Is there a CPAN module which provides the functionality of ¥/zip() for
> Perl5?

[Luke Palmer]

On 10/21/05, Mark Reed <mark...@turner.com> wrote:
> Hm. This brings up another point, which may have been addressed . . .
>
> The Python function and Ruby array method zip() both accept any number of
> arrays to interleave:
>
> >>> zip([1,2,3],[4,5,6],[7,8,9])
> [(1, 4, 7), (2, 5, 8), (3, 6, 9)]
>
> irb(main):001:0> [1,2,3].zip([4,5,6],[7,8,9])
> => [[1, 4, 7], [2, 5, 8], [3, 6, 9]]
>
> How would you write the above in Perl6, given that ¥/Y is an infix operator?

Ah, ¥ is not a binary infix operator. Instead, it is what Damian
calls "list-associative". Another such operator is junctive ^, for if
it were binary, it would be an xor, not a one.

As far as the syntax goes, well, we'll have to make some up.

sub listfix:<¥> (Array *@arrays) {...}
sub infix:<¥> is assoc('list') (Array *@arrays) {...}

Or something like that.

However, if I get my wish of having zip return tuples, then it can be
left-associative. But since it interleaves instead, making it left-
or right-associative gives strange, incorrect results.

Luke

[Larry Wall]

On Fri, Oct 21, 2005 at 04:04:25PM -0600, Luke Palmer wrote:
: However, if I get my wish of having zip return tuples, then it can be

: left-associative. But since it interleaves instead, making it left-
: or right-associative gives strange, incorrect results.

I expect zip ought to bundle up into tuples of some sort. But then
maybe zip is not what we want for typical loops. I'm thinking that
"for" wants to be a little more incestuous with -> anyway, so that
the optionality of the -> arguments can tell "for" how to deal with
short lists. And now that we have general multidimensional slices,
it'd be nice if "for" were one of the operators that is aware of that.
Then you might be able to say things like:

for (@foo; 1...) -> $val, $i {...}

for @foo <== 1... -> $val, $i {...}

1... ==>
for @foo -> $val, $i {...}

1... ==> #######v
@foo ==> #v v
for () -> $val, $i {...}

all of which should in theory be equivalent, and none of which use "zip".
(With a bit of handwaving about how ==> binds to the list before
a final -> block.)

With a clever enough parser, we even get back to the A4 formulation of

for @foo; 1... -> $val, $i {...}

But that's relying on the notion that a statement can function as a
funny kind of bracketing device that can shield that semicolon from
thinking it's supposed to terminate the statement. That's probably
not too far off from what it does now when it knows it wants a final
block, so that a bare block where an operator is expected pops back
up to the statement level.

I know that, with tuple matching signatures, zip can be made to work
even as a tuple constructor, but it seems like a waste to constuct
tuples only to throw them away immediately. And if we're going to
build surreal lists into the language, we should probably use them.

Larry