Proposal: Bring the Contravariant class to base

[Dmitry Olshansky]

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

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

> 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 gmail.com> 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] http://hackage.haskell.org/package/contravariant-1.4/doc
>> s/Data-Functor-Contravariant.html#t:Contravariant
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170914/2ebbf6b6/attachment-0001.html>