We don't strictly *need* to add either of these functions. Users can use munzip from the MonadZip instance, and we can add a rewrite rule to turn munzip (fmap f xs) into Data.Sequence.Internal.unzipWith f xs On the other hand, MonadZip isn't a terribly well-known class, and unzipWith has always struck me as an obvious analogue of zipWith. On Jan 11, 2018 10:32 PM, "Ivan Lazar Miljenovic" <ivan.miljenovic@gmail.com> wrote:

On 12 January 2018 at 13:28, David Feuer <david.feuer@gmail.com> 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?

I see no problem with this. Though I think it's worth pointing out that Data.List doesn't have unzipWith (though unzipWith f = unzip . map f).

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

I have found from time to time, when using Data.Sequence, that a list-like function that I expect to be there is in fact not present and its absence is not mentioned; it always turns out to be implicit in one of Sequence's instances. Examples: map, fold, (++). This is in principle no different, except that MonadZip is apparently relatively obscure and, possibly, not the "right" class according to Tony Morris' link. I can't tell if this is an argument for or against the proposal, but it does seem to reflect a choice to populate the Sequence API via instantiating standard classes rather than writing standalone functions (with possibly conflicting names, not that this is a new thing with these container libraries). Both map and fold have Seq-specific indexed variants that are *not* part of those classes, and if neatness is what the module authors were going for, then this kind of variation is the only thing that should actually appear in Data.Sequence itself. It does impact the usefulness of the documentation, though. I think that's the real issue here. On Thu, Jan 11, 2018 at 10:47 PM, Tikhon Jelvis <tikhon@jelv.is> wrote:

I did not know about MonadZip and wouldn't have thought to look for it.

On the other hand, unzip and unzipWith are immediately intuitive.

I think they'd be a solid addition.

On Thu, Jan 11, 2018 at 8:54 PM, David Feuer <david.feuer@gmail.com> wrote:

...

We don't strictly *need* to add either of these functions. Users can use munzip from the MonadZip instance, and we can add a rewrite rule to turn

munzip (fmap f xs)

into

Data.Sequence.Internal.unzipWith f xs

On the other hand, MonadZip isn't a terribly well-known class, and unzipWith has always struck me as an obvious analogue of zipWith.

On Jan 11, 2018 10:32 PM, "Ivan Lazar Miljenovic" < ivan.miljenovic@gmail.com> wrote:

...

On 12 January 2018 at 13:28, David Feuer <david.feuer@gmail.com> 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?

I see no problem with this. Though I think it's worth pointing out that Data.List doesn't have unzipWith (though unzipWith f = unzip . map f).

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

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

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

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 <tmorris@tmorris.net> 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 <david.feuer@gmail.com> 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