
That's a good point about the deriving ambiguity. I had not really thought that through all the way. Additionally, I just stumbled across https://github.com/ekmett/contravariant/issues/17, which makes it pretty clear that there actually isn't a good way to handle all cases. I think that it might still be nice to have a DeriveContravariant that is simply weaker than DeriveFunctor. It could just complain and error out in ambiguous cases. The ambiguous cases would be all types parameterized by more than one higher-kinded type. And DeriveFunctor could just be left alone, continuing to derive the Functor instance for Compose the same way it already does. Usually, when I write Contravariant instances, it's for stuff like this that doesn't even involve anything higher-kinded: data Encoding c a = Encoding (Vector (c, a -> c)) Of course, I could be totally wrong about the rule I suggested for figuring out ambiguous cases. I guess I probably need to think about it more. Regardless, I'm glad to hear that someone else is in favor of moving Contravariant into base. On Sun, Dec 11, 2016 at 12:05:05PM -0800, Shachaf Ben-Kiki wrote:
Putting Contravariant in base sounds like a reasonable thing to do. It's a pretty basic class.
Deriving Contravariant seems a bit tricky. If Contravariant is in base and part of the deriving code, what Functor/Contravariant instances do you derive for e.g. newtype Compose f g a = Compose (f (g a))?
Shachaf
On Sun, Dec 11, 2016 at 8:14 AM, Andrew Martin
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