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

The border doesn't need to be awkward, but it does need to be exquisitely
carefully designed.

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.

If you consider these to be part of "assembling the computation", you have
to be really careful when you abstract out part of your assembly, because
they'll be super-expensive if you don't cache them, and you won't even save
any memory because it's all created anyway.

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.

I'm not saying you can't make a clean and correct, but the naive ways to do
these things either leave you with a pretty impoverished (by Scala
standards) set of collections methods, or contain major traps/pitfalls.

It's not as simple as "not eager" or "assembly vs execution".  That's part
of the puzzle, but it's a tricky puzzle to get right.  So Scala's approach
of keeping the efficiency easy to understand by making everything eager is
not _such_ a woefully bad idea, even if I agree that with sufficient care
something better could (very likely) be crafted.

 --Rex


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

> Then it has to be "lazy" in the same sense as a non-executed database
> query is lazy. :-)
>
> The border doesn't need to be awkward, it comes naturally when we make a
> distinction between assembling the computation to be run, and executing it.
> Mixing them together is the root issue behind sequential vs. parallel vs.
> iterator vs. sequential views vs. parallel views vs. Slick vs. Spark
> implementations of the same thing.
>
> These days I would consider an API that provides
> map/flatMap/filter/groupBy/join/... and talks about how it is
> implemented/executed conceptually wrong. It causes issues without solving
> any.
>
> --
> 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.