Concat and zip

[Joe Bowbeer]

I like concat, too, but AFAICT zip was the only one on the chopping block,
so that's the only one I posted a defense for.


On Fri, May 3, 2013 at 3:31 PM, Dan Smith <daniel.smith at oracle.com> wrote:

> On May 1, 2013, at 3:15 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
> > So far I'm seeing:
> >
> > - No one throwing themselves in front of the train for concat
>
> That's crazy talk.  _Of course_ we need concat.  IMHO, one of the most
> important use cases for lazy lists is being able to paste things together
> on the front or back without iterating/making copies.
>
> Is there a reasonable workaround if the libraries don't provide it?
>
> It would be more natural if concat were a default method: Stream.andThen,
> Stream.after.
>
> I also think primitive concat is pretty fundamental for primitive streams.
>
> > - No one throwing themselves in front of the train for primitive zip
> > - Widespread regret if we were to ditch reference zip
>
> I'm much less adamant about this, but as a PL guy, I often find myself
> wanting to match up two lists (e.g., arguments with parameters).
>
> Again, what's the workaround?  The current code in Streams does not look
> particularly easy to get right if I'm rolling my own.
>
> Once possible concern that hasn't been mentioned: will this play well with
> a future BiStream version, or will it look out of place at that point?
>  (Presumably we'll be able to say 'Streams.zip(x,
> y).combine(SomeClass::new)' someday.)
>
> > 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?
>
> > Zip shows up all over the place in functional languages, but the
> efficacy of these idioms relies on tuples being cheap.  Also zip
> parallelizes basically not at all.
>
> - What's great about the BiFunction style (vs. a Pair-generating style) is
> that you don't need any tuples at all.  Hence, I'm not seeing "new object
> per element" in the code.  Am I missing something?
>
> - I wouldn't take away too many points if a feature that is primarily
> about expressiveness does not parallelize nicely.
>
> ---
>
> I'm pretty sure you're not asking for new suggestions :-), but I wouldn't
> complain about a cross-product method to complement zip.
>
> —Dan