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

> 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.