Move Data.Functor.Contravariant into base

[Edward Kmett]

I have no particular issue with moving Contravariant into base.

That said, DeriveContravariant doesn't work out as well as you'd think. See
the discussion in here: https://github.com/ekmett/contravariant/issues/17
(There were other, longer discussions elsewhere that were er.. more of a
discussion, but they were mostly on places like #haskell-lens which aren't
logged and I can't find them at the moment.)

With covariance you can just ignore that contravariant cases exist and get
reasonable deriving.

With contravariance composition of contravariant functors is covariant. You
have the f (g a) problem. Which of the two is contravariant? This doesn't
arise solely from type arguments. When faced with a concrete data type, you
can't just look for a Contravariant or Functor instance for it, because
both might be available (think Proxy). So the whole extension becomes a
bug-addled mess.

e.g. There are two sensible Contravariant instances for Compose, but
neither one is canonical.

The other DeriveFoo definitions all do reasonable things. This can't do a
reasonable thing in any non-trivial situation.

-Edward

On Sun, Dec 11, 2016 at 11:14 AM, Andrew Martin <andrew.thaddeus at gmail.com>
wrote:

> The typeclass Contravariant (from the contravariant package) is both
> useful and fundamental. I would like to see this moved into base.
> One additional motivating factor is that it would become possible
> for a DeriveContravariant extension to be written in a future GHC
> release.  I'd love to hear other people's thoughts, even if it's as
> simple as a yea or nay. Thanks.
>
> -Andrew Martin
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20161213/57036a23/attachment.html>