Re: &zip

[Rod Adams]

Larry Wall wrote:
If we go with my once-upon-a-time notion of using zip(@a;@b), then it
naturally comes in as [EMAIL PROTECTED],[EMAIL PROTECTED]
 

It pretty much has to use the list of lists syntax, since the number of 
Arrays we are zipping is variadic, and that means using a slurpy, which 
would flatten the arrays into one. So the semicolons stay. Unless 
there's a non-flattening slurpy syntax out there....

: As a second matter, can you declare a type for the elements of a slurpy 
: array?

Yes, and it distributes as any array return type declaration would.
 

Does this mean that we can define multiple slurpuy arrays (and 
hashes?!?) in a parameter list, of different types, and Perl will sort 
the arguments into the right slurpy for us? If so, how does this 
interact with the answer about C<@CALLER::_>?

: So far I have:
: 
: multi sub zip (Array [EMAIL PROTECTED]) returns List {
:   gather {
:     while any(@lists) {

any() is not guaranteed to produce left-to-right order.
 

I'm not counting on it being ordered.  I'm testing to see if any of the 
lists still has anything left in it. The left to right-ness of the 
processing is done in the C<for>.

:       for @lists -> @list {
:         take shift @list;
:       }
:     }
:   }
: }
: 
: But I can't tackle the lvalue problem.

Why do they need to be lvalues?  I always thought of zip as non-destructive.
Has zip historically been destructive in other languages?
 

I wasn't aware of a C<zip> in other languages.
My thought was that people might want to update the values stored 
inside, as an homage to my common Perl 5 construct:

 for ($var1, $var2) {
    s/.../.../;
    s/.../.../;
 }
(and yes, I'm a bit chagrined that Perl6 is converting that lovely thing to:
 for $var1, $var2 -> $_ is rw {
    s/.../.../;
    s/.../.../;
 }
though
 given $var1 {
    s/.../.../;
    s/.../.../;
 }
is nice.
)
But if you don't see the need for lvalueing the elements coming out of 
C<zip>, that certainly makes things easier. :-)

-- Rod Adams