Proposal: Bring the Contravariant class to base

Andrew Martin andrew.thaddeus at
Wed Sep 13 13:13:01 UTC 2017

I am +1 on this. Like others, I also only want Data.Functor.Contravariant,
not the rest of the machinery in there. As a historical data point, I
proposed this a year ago (,
but the we ended up on a tangent why a DeriveContravariant wouldn't really
be possible, and the original proposal went nowhere. So, as a piece of
advice, don't talk about DeriveContravariant ;)

On Tue, Sep 12, 2017 at 5:44 PM, Daniel Díaz Casanueva <
dhelta.diaz at> wrote:

> Dear haskellers,
> I admit I might not have the strongest arguments here, but I thought that
> I would share my opinion anyway, and maybe get other people's perspectives.
> I would like to propose bringing the Contravariant class [1] to base.
> I know, base keeps growing, and maybe there is no need for it to grow
> further without a strong argument, but I do feel like Contravariant is a
> simple, very basic class, that would receive better and greater use if
> included in base. Contravariant is very similar to Functor (some people
> call it CoFunctor), but in `contramap` (Contravariant's `fmap`) the "arrow"
> of the applied function goes in the opposite direction. I think that
> `contramap` can be useful for many types, just like `fmap` is for many
> others, but we don't use it because it's not yet so popular, or maybe
> because it requires the contravariant package to be included as dependency
> (although personally I don't think that is a real problem). The
> contravariant package itself provides a plentiful of instances, many of
> them for types in base.
> In a real world scenario I had, it was very useful to add a Contravariant
> instance to `Data.Aeson.ToJSONKeyFunction`, that perhaps is not included
> in aeson because either it was not desired to add the contravariant package
> as dependency, or simply because Contravariant is not so well-known. Note
> that, however, `FromJSONKeyFunction` _is_ instance of Functor. Even though
> both instances are equally natural and useful in this context, only one of
> them was implemented. This probably would not have happened if
> Contravariant was in base.
> So, in my opinion, for the sake of completeness, I think we should add
> Contravariant to base, just as we have Functor. Note that my proposal does
> not necessarily include the rest of types and functions defined in the
> contravariant package.
> Best regards,
> Daniel Casanueva
> # References
> [1]
> docs/Data-Functor-Contravariant.html#t:Contravariant
> _______________________________________________
> Libraries mailing list
> Libraries at

-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list