Concat and zip

[Raab, Donald [Tech]]

OK, so a day later, we had 3 folks report back with 4 instances of using zip with GS Collections.  Two of the folks are fluent in Python and Lisp.  There are probably more instances.  One of the interesting things about zip is that unless you have programmed in a functional language, you probably won't know it even exists as a pattern.  But if you have, you might go looking for it.  

> -----Original Message-----
> From: Sam Pullara [mailto:spullara at gmail.com]
> Sent: Wednesday, May 01, 2013 5:13 PM
> To: Raab, Donald [Tech]
> Cc: 'Brian Goetz'; 'Tim Peierls'; 'lambda-libs-spec-
> experts at openjdk.java.net'
> Subject: Re: Concat and zip
> 
> It seems useful enough for the Object case to keep it in but not worth
> its weight to add it to the primitive stuff.
> 
> Sam
> 
> On May 1, 2013, at 1:51 PM, "Raab, Donald [Tech]" <Donald.Raab at gs.com>
> wrote:
> 
> > I'm polling to see how many users of GS Collections have used zip
> internally.  We have it on our object API, not on our primitive API.
> I'll let you know the response I get in the next day or so.
> >
> >> -----Original Message-----
> >> From: lambda-libs-spec-experts-bounces at openjdk.java.net
> >> [mailto:lambda- libs-spec-experts-bounces at openjdk.java.net] On
> Behalf
> >> Of Brian Goetz
> >> Sent: Wednesday, May 01, 2013 4:43 PM
> >> To: Tim Peierls
> >> Cc: lambda-libs-spec-experts at openjdk.java.net
> >> Subject: Re: Concat and zip
> >>
> >> Yes, a key aspect of this YAGNI suggestion is that this is one of
> the
> >> things people CAN do for themselves, possibly with an example.  And,
> >> because there are multiple ways to do zip (pad out shorter stream to
> >> size of longer stream, stop at end of shorter stream, throw if
> >> streams are not of equal length) people may well want to roll their
> own.
> >>
> >> On 5/1/2013 4:25 PM, Tim Peierls wrote:
> >>> On Wed, May 1, 2013 at 4:03 PM, Joe Bowbeer <joe.bowbeer at gmail.com
> >>> <mailto:joe.bowbeer at gmail.com>> wrote:
> >>>
> >>>    In defense of zip: I think it is fairly important.  Ease of
> >>>    expression (and productivity) are still the most valuable
> >> benefits
> >>>    of new features, and zip is important for a class of problems.
> >> zip
> >>>    exists in Python, Scala, and Groovy (as "transpose" method), to
> >> name
> >>>    a few.
> >>>
> >>>    I would keep zip without Int/Long/Double versions.  This also
> >> avoids
> >>>    all the varieties of mixed primitive/Object pairings in zipped
> >> streams.
> >>>
> >>>
> >>> That sounds reasonable. I was going to say make the ref/ref version
> >> an
> >>> example in javadoc and then people can roll their own primitive/ref
> >>> versions, but maybe that's asking too much.
> >>>
> >>> --tim