Concat and zip
joe.bowbeer at gmail.com
Mon May 6 00:10:14 PDT 2013
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,
> 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.
More information about the lambda-libs-spec-observers