Re: Re: Shouldn't collection zip functions return streams?

If you're going to go all the way to Akka Streams where you build the
processing graph in advance, then I agree.

Otherwise, no.  You're favoring a particular kind of application, where you
do exactly one thing with your data (single linear pipeline), and
neglecting the application where you do some processing and then several
different things from that result, and then branch off again from those.

Providing natural nodes for actual materialization really helps build
efficient processing trees.

  --Rex


On Sat, Nov 28, 2015 at 8:06 PM, Simon Ochsenreither <
[email protected]> wrote:

>
> Consider groupBy, for example.  There are zero ways to do this that don't
>> require the entire collection to be rebuilt in the general case.  Likewise
>> with sorted or partition.
>>
>
> I think every major database vendor will disagree with that.
> One benefit of being able to look at the whole computation is that
> optimization steps can be shared, so even if we have constraints for the
> general case, there are plenty of things that can be done looking at
> specific computations. Database vendors have done that for decades. Haskell
> does it in GHC, too. We could do it in a library.
>
> (Additionally, that's what I was talking about regarding "I would consider
> an API that provides map/flatMap/filter/groupBy/join/... and talks about
> how it is implemented/executed conceptually wrong".)
>
> The map/flatMap/filter/groupBy/join/... API should not be rebuilding
> anything, in fact it should be do nothing at all except represent a
> computation.
>
> So, if they're not minefields to trap the unwary coder, they need to
>> require execution.  But then you commit yourself to a large set of eager
>> and non-eager methods, which can be tricky to keep straight.
>>
>
> No, that doesn't follow. Having these large sets of eager vs. non-eager
> methods is one of the major pain points of the current state of the art. I
> want to get away from that. Again, the whole distinction about how
> operations are executed is tackling the problem at the wrong level.
>
> --
> You received this message because you are subscribed to the Google Groups
> "scala-language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.