Loose end: zip

[Joe Bowbeer]

I have not used this zip, actually, and I just tried to use it and I was
not pleased.

When I use zip, I'm usually pairing keys to items.  Usually the keys are
ints and the items are some app-specific object, or maybe just a string:

zipped = zip(ints(), collection.stream());

*This* version of zip requires me to supply a third "zipper" argument,
which means I also have to make up a type for the pairs.

What I really want is a zip that returns Stream<Pair<A,B>> so I don't have
to deal with the pairing:

<A,B> Stream<Pair<A,B>> zip(Stream<? extends A> a, Stream<? extends B> b)

--Joe


On Thu, Jun 6, 2013 at 4:53 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Has anyone on the EG experimented with *this* version of zip?  Do you have
> experience to report?
>
>
> On 6/6/2013 6:58 PM, Joe Bowbeer wrote:
>
>> I don't think I have anything to add to what I already said: zip is an
>> expressive, useful tool.
>>
>> Java programmers effectively use maps of maps, and maps of lists, and
>> lists of maps, and all kinds of inefficient things.
>>
>> Originally, Java's biggest advantage was its increased productivity.
>>   That one advantage can make up for lots of little disappointments.
>>
>> I definitely don't want to have to search for a zip snippet somewhere
>> (e.g., in Fugue?).  A basic tool like zip is not something I would look
>> for in an extension library.
>>
>> Regarding the no-primitive versions, I think the consensus was to live
>> with that.
>>
>>
>> On Thu, Jun 6, 2013 at 12:49 PM, Brian Goetz <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com**>> wrote:
>>
>>     Still feeling kind of YAGNI on zip, for the reasons cited in the
>>     message below, plus:
>>       - No primitive versions (would require new SAMs)
>>       - Hard to parallelize
>>       - Multiple ways to deal with streams of different length; we pick
>> one
>>
>>     Might this be something best provided by some other library than the
>>     JDK?  Or as a code example somewhere people can crib from to roll
>>     their own?
>>
>>     On 5/1/2013 5:10 PM, Brian Goetz wrote:
>>
>>         Right, but the question is, how badly can we implement it and
>>         have it
>>         not be worse than nothing?  And, with the current performance
>>         characteristics (new object per element), are we below that
>>         threshold?
>>
>>         My problem is the same as with flatMap -- these are idioms from
>>         other
>>         languages that *translate poorly* to Java because of the lack of
>>         tuples
>>         and other structural types.  (The flatMap we got left with --
>>         which I
>>         reluctantly supported as the lesser of evils -- is,
>>         coincidentally, the
>>         only other stream operation that has allocation-per-element.)
>>           At what
>>         level of translation-fidelity loss do we say "yeah, it works
>>         great in
>>         that other environment, but too much is lost in translation"?
>>
>>         I don't doubt the utility of zip, or the fact that Joe-alikes
>>         will want
>>         it, and would be bummed to not find it.  My question is whether
>> the
>>         crappy zip we can have is better than no zip.  (Where better
>> doesn't
>>         just mean "better than nothing", but carries its weight.)
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130608/140ba741/attachment.html