Proposal: Bring the Contravariant class to base

[Siddhanathan Shanmugam]

I find Contravariant functors to be a nice abstraction. +1 on this.

- Sid

On Wed, Sep 13, 2017 at 11:08 AM, Aloïs Cochard <alois.cochard at gmail.com>
wrote:

> Hi there,
>
> Just to say I'm all for it as well, wanted that in base a few time in the
> past...
>
> Cheers
>
> On 13 September 2017 at 15:13, Andrew Martin <andrew.thaddeus at gmail.com>
> wrote:
>
>> 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 (
>> http://haskell.1045720.n5.nabble.com/Move-Data-Functor-Cont
>> ravariant-into-base-td5847730.html), 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 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
>>>
>>>
>>
>>
>> --
>> -Andrew Thaddeus Martin
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>
>
> --
> *Λ\oïs*
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard
>
> _______________________________________________
> 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/20170913/3f3d05d1/attachment.html>