Data.Functor.unzipF (Was: Data.Map.unzip?)

[David Feuer]

I hate using RULES for this sort of thing. Logically, we should probably
have Unzippable f => Functor f, but that's unlikely to fly. We could do
that evil default signature thing for an Unzippable class.
On Dec 5, 2014 5:49 PM, "Joachim Breitner" <mail at joachim-breitner.de> wrote:

> Hi,
>
>
> Am Freitag, den 05.12.2014, 17:38 -0500 schrieb David Feuer:
>
> >
> >         Am Freitag, den 05.12.2014, 14:09 -0800 schrieb Eric Mertens:
> >         > Would it be significantly better than just having/using the
> >         following
> >         > definition?
> >         >
> >         > unzipF :: Functor f => f (a, b) -> (f a, f b)
> >         > unzipF x = (fmap fst x, fmap snd x)
> >
> >         yes, I guess that would be sufficient. Something for
> >         Data.Functor?
> >
> > This looks like it should be the default implementation of an
> > Unzippable class, rather than a standalone function.
> >
>
> Clearly, every Functor isunzippable.
>
> What do you expect to be Unzippable that is not a functor?
>
> Or are you worried about performance, and allow better implementations?
> Then I hope we can do that without touching the desired API, e.g. using
> RULEs.
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141205/66cd73c4/attachment-0001.html>