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@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries