Move Data.Functor.Contravariant into base

Andrew Martin andrew.thaddeus at gmail.com
Sun Dec 11 22:10:24 UTC 2016


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
> <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


More information about the Libraries mailing list