Discussion:
Proposal: add unzips for Data.Sequence
David Feuer
2018-01-12 03:28:37 UTC
Permalink
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?
Ivan Lazar Miljenovic
2018-01-12 03:32:19 UTC
Permalink
Post by David Feuer
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
***@gmail.com
http://IvanMiljenovic.wordpress.com
David Feuer
2018-01-12 04:54:29 UTC
Permalink
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.
Post by Ivan Lazar Miljenovic
Post by David Feuer
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
http://IvanMiljenovic.wordpress.com
Tikhon Jelvis
2018-01-12 06:47:46 UTC
Permalink
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.
Post by David Feuer
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" <
Post by Ivan Lazar Miljenovic
Post by David Feuer
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
http://IvanMiljenovic.wordpress.com
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Ryan Reich
2018-01-12 07:36:08 UTC
Permalink
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.
Post by Tikhon Jelvis
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.
Post by David Feuer
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" <
Post by Ivan Lazar Miljenovic
Post by David Feuer
Paolo G. Giarrusso (Blaisorblade) would like to add an unzip function
to
Post by David Feuer
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
http://IvanMiljenovic.wordpress.com
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Tony Morris
2018-01-12 07:07:50 UTC
Permalink
This idea has been around a while:

https://hackage.haskell.org/package/category-extras-0.52.1/docs/Control-Functor-Zip.html

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)
Post by David Feuer
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
David Feuer
2018-01-12 07:31:29 UTC
Permalink
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/
Post by Tony Morris
https://hackage.haskell.org/package/category-extras-0.52.1/docs/Control-Functor-Zip.html
http://comonad.com/reader/2008/zipping-and-unzipping-functors/
\x -> (fmap fst x, fmap snd x)
Post by David Feuer
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Loading...