<div dir="ltr"><div>One that popped up for me recently was the Size data type in the store package[1]. The Contravariant instance can be useful for defining new serializable types in terms of existing types.</div><div><br></div><div>Also: +1 for including in base.<br></div><div><br></div><div>[1] <a href="https://www.stackage.org/haddock/lts-9.4/store-0.4.3.2/Data-Store.html#t:Size">https://www.stackage.org/haddock/lts-9.4/store-0.4.3.2/Data-Store.html#t:Size</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 13, 2017 at 10:45 PM, Evan Laforge <span dir="ltr"><<a href="mailto:qdunkan@gmail.com" target="_blank">qdunkan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just for the curiosity of those following at home, are there any<br>
articles out there discussing what contramap is good for?  Or maybe<br>
just some simple examples?  I've only seen the<br>
<a href="https://www.schoolofhaskell.com/school/to-infinity-and-beyond/pick-of-the-week/profunctors" rel="noreferrer" target="_blank">https://www.schoolofhaskell.<wbr>com/school/to-infinity-and-<wbr>beyond/pick-of-the-week/<wbr>profunctors</a><br>
one, and it basically repeats the instances built-in to the<br>
contravariant package, which is compose things on the front of a<br>
function.  And generalizations that to where the function takes<br>
multiple args of the same type it can apply to all of them, which is<br>
the 'compare' instance and ToJSONKeyFunction is also in that boat.  So<br>
I guess it's a generalized way to adjust the input to a function-like<br>
type?  Any other examples?<br>
<br>
I use fmap all the time, but I've never used contramap, so I'm curious<br>
if I'm missing something useful.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Sep 13, 2017 at 10:33 AM, Siddhanathan Shanmugam<br>
<<a href="mailto:siddhanathan%2Beml@gmail.com">siddhanathan+eml@gmail.com</a>> wrote:<br>
> I find Contravariant functors to be a nice abstraction. +1 on this.<br>
><br>
> - Sid<br>
><br>
><br>
> On Wed, Sep 13, 2017 at 11:08 AM, Aloïs Cochard <<a href="mailto:alois.cochard@gmail.com">alois.cochard@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi there,<br>
>><br>
>> Just to say I'm all for it as well, wanted that in base a few time in the<br>
>> past...<br>
>><br>
>> Cheers<br>
>><br>
>> On 13 September 2017 at 15:13, Andrew Martin <<a href="mailto:andrew.thaddeus@gmail.com">andrew.thaddeus@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> I am +1 on this. Like others, I also only want<br>
>>> Data.Functor.Contravariant, not the rest of the machinery in there. As a<br>
>>> historical data point, I proposed this a year ago<br>
>>> (<a href="http://haskell.1045720.n5.nabble.com/Move-Data-Functor-Contravariant-into-base-td5847730.html" rel="noreferrer" target="_blank">http://haskell.1045720.n5.<wbr>nabble.com/Move-Data-Functor-<wbr>Contravariant-into-base-<wbr>td5847730.html</a>),<br>
>>> but the we ended up on a tangent why a DeriveContravariant wouldn't really<br>
>>> be possible, and the original proposal went nowhere. So, as a piece of<br>
>>> advice, don't talk about DeriveContravariant ;)<br>
>>><br>
>>> On Tue, Sep 12, 2017 at 5:44 PM, Daniel Díaz Casanueva<br>
>>> <<a href="mailto:dhelta.diaz@gmail.com">dhelta.diaz@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Dear haskellers,<br>
>>>><br>
>>>> I admit I might not have the strongest arguments here, but I thought<br>
>>>> that I would share my opinion anyway, and maybe get other people's<br>
>>>> perspectives. I would like to propose bringing the Contravariant class [1]<br>
>>>> to base.<br>
>>>><br>
>>>> I know, base keeps growing, and maybe there is no need for it to grow<br>
>>>> further without a strong argument, but I do feel like Contravariant is a<br>
>>>> simple, very basic class, that would receive better and greater use if<br>
>>>> included in base. Contravariant is very similar to Functor (some people call<br>
>>>> it CoFunctor), but in `contramap` (Contravariant's `fmap`) the "arrow" of<br>
>>>> the applied function goes in the opposite direction. I think that<br>
>>>> `contramap` can be useful for many types, just like `fmap` is for many<br>
>>>> others, but we don't use it because it's not yet so popular, or maybe<br>
>>>> because it requires the contravariant package to be included as dependency<br>
>>>> (although personally I don't think that is a real problem). The<br>
>>>> contravariant package itself provides a plentiful of instances, many of them<br>
>>>> for types in base.<br>
>>>><br>
>>>> In a real world scenario I had, it was very useful to add a<br>
>>>> Contravariant instance to `Data.Aeson.ToJSONKeyFunction`<wbr>, that perhaps is<br>
>>>> not included in aeson because either it was not desired to add the<br>
>>>> contravariant package as dependency, or simply because Contravariant is not<br>
>>>> so well-known. Note that, however, `FromJSONKeyFunction` _is_ instance of<br>
>>>> Functor. Even though both instances are equally natural and useful in this<br>
>>>> context, only one of them was implemented. This probably would not have<br>
>>>> happened if Contravariant was in base.<br>
>>>><br>
>>>> So, in my opinion, for the sake of completeness, I think we should add<br>
>>>> Contravariant to base, just as we have Functor. Note that my proposal does<br>
>>>> not necessarily include the rest of types and functions defined in the<br>
>>>> contravariant package.<br>
>>>><br>
>>>> Best regards,<br>
>>>> Daniel Casanueva<br>
>>>><br>
>>>> # References<br>
>>>><br>
>>>> [1]<br>
>>>> <a href="http://hackage.haskell.org/package/contravariant-1.4/docs/Data-Functor-Contravariant.html#t:Contravariant" rel="noreferrer" target="_blank">http://hackage.haskell.org/<wbr>package/contravariant-1.4/<wbr>docs/Data-Functor-<wbr>Contravariant.html#t:<wbr>Contravariant</a><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> Libraries mailing list<br>
>>>> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> -Andrew Thaddeus Martin<br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> Libraries mailing list<br>
>>> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Λ\oïs<br>
>> <a href="http://twitter.com/aloiscochard" rel="noreferrer" target="_blank">http://twitter.com/<wbr>aloiscochard</a><br>
>> <a href="http://github.com/aloiscochard" rel="noreferrer" target="_blank">http://github.com/aloiscochard</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Libraries mailing list<br>
>> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
>><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
><br>
______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>