Re: Proposal: add unzips for Data.Sequence

The semantics that seem most natural from an implementation standpoint are unzip xs = xs `seq` (fmap fst xs, fmap snd xs) Is there some reason that extra drop of strictness will be troublesome? It is true that all functors give an unzip, but it seems valuable to offer a custom version anyway for situations where the universal implementation could lead to a space leak. For example, suppose I have a function f :: A -> (B, C) where B is very large and C is not. Suppose I then let (bs, cs) = unzipWith f xs immediately fold bs up into a small summary value, and never use bs again. With the universal implementation of unzip, all the B values will be kept alive by cs. With the hand-written implementation, assuming the GC hack works out [*], we should be able to free the Bs promptly. Of course, nothing is free, so we'll build up some structure for cs even if we never use it. I think it makes sense to offer users the choice. [*] http://homepages.inf.ed.ac.uk/wadler/papers/leak/ On Fri, Jan 12, 2018 at 2:07 AM, Tony Morris wrote:

This idea has been around a while:

https://hackage.haskell.org/package/category-extras-0.52.1/docs/Control-Func...

Here is an article:

http://comonad.com/reader/2008/zipping-and-unzipping-functors/

Note that all functors give unzip:

\x -> (fmap fst x, fmap snd x)

On Fri, Jan 12, 2018 at 1:28 PM, David Feuer wrote:

...

Paolo G. Giarrusso (Blaisorblade) would like to add an unzip function to Data.Sequence. I agree. I propose adding

unzip :: Seq (a,b) -> (Seq a, Seq b)

unzipWith :: (x -> (a, b)) -> Seq x -> (Seq a, Seq b)

Does anyone object?

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries