Proposal: add unzips for Data.Sequence

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: add unzips for Data.Sequence

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add unzips for Data.Sequence

Ivan Lazar Miljenovic
On 12 January 2018 at 13:28, David Feuer <[hidden email]> 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
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add unzips for Data.Sequence

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" <[hidden email]> wrote:
On 12 January 2018 at 13:28, David Feuer <[hidden email]> 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
[hidden email]
http://IvanMiljenovic.wordpress.com

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add unzips for Data.Sequence

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.

On Thu, Jan 11, 2018 at 8:54 PM, David Feuer <[hidden email]> 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" <[hidden email]> wrote:
On 12 January 2018 at 13:28, David Feuer <[hidden email]> 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
[hidden email]
http://IvanMiljenovic.wordpress.com

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add unzips for Data.Sequence

Tony Morris
In reply to this post by David Feuer
\x -> (fmap fst x, fmap snd x)


On Fri, Jan 12, 2018 at 1:28 PM, David Feuer <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add unzips for Data.Sequence

David Feuer
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 <[hidden email]> wrote:

> 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)
>
>
> On Fri, Jan 12, 2018 at 1:28 PM, David Feuer <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add unzips for Data.Sequence

Ryan Reich
In reply to this post by Tikhon Jelvis
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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> wrote:
On 12 January 2018 at 13:28, David Feuer <[hidden email]> 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
[hidden email]
http://IvanMiljenovic.wordpress.com

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries