Proposal: Bring the Contravariant class to base

Dmitry Olshansky olshanskydr at
Thu Sep 14 09:39:34 UTC 2017

Maybe `cmap` is better name than `contramap` here?

2017-09-13 16:02 GMT+03:00 Edward Kmett <ekmett at>:

> I'd be open to merging the existing Data.Functor.Contravariant module into
> base (inverting dependencies as needed), while leaving the remainder of the
> contravariant package intact. This module contains the class and a couple
> of example contravariant functors, much in the same vein as Data.Monoid.
> This would leave the more exotic machinery for 'contravariant applicatives'
> and all the generic programming bits in the package.
> +1
> This would be similar to the migration of Data.Proxy from tagged into
> base, which left behind Data.Tagged or the migration of Data.Semigroup from
> semigroups, which left behind the generics module.
> Almost all of the dependencies that would have inversions are packages I
> maintain personally. The only package that would require coordination with
> another maintainer would be inverting the instances for data types supplied
> by transformers.
> If there was a sufficient call for it, I'd be open to moving the rest into
> base, but I don't anticipate a great deal of demand and this could always
> happen at a later date or as part of another proposal, should this change.
> -Edward
> On Tue, Sep 12, 2017 at 11: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]
>> s/Data-Functor-Contravariant.html#t:Contravariant
>> _______________________________________________
>> Libraries mailing list
>> Libraries at
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list