Proposal: Bring the Contravariant class to base
Aloïs Cochard
alois.cochard at gmail.com
Wed Sep 13 15:08:51 UTC 2017
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-Contravariant-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170913/4a33ad13/attachment-0001.html>
More information about the Libraries
mailing list