Proposal: Bring the Contravariant class to base

[Michael Snoyman]

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.

Also: +1 for including in base.

[1]
https://www.stackage.org/haddock/lts-9.4/store-0.4.3.2/Data-Store.html#t:Size

On Wed, Sep 13, 2017 at 10:45 PM, Evan Laforge <qdunkan at gmail.com> wrote:

> Just for the curiosity of those following at home, are there any
> articles out there discussing what contramap is good for?  Or maybe
> just some simple examples?  I've only seen the
> https://www.schoolofhaskell.com/school/to-infinity-and-
> beyond/pick-of-the-week/profunctors
> one, and it basically repeats the instances built-in to the
> contravariant package, which is compose things on the front of a
> function.  And generalizations that to where the function takes
> multiple args of the same type it can apply to all of them, which is
> the 'compare' instance and ToJSONKeyFunction is also in that boat.  So
> I guess it's a generalized way to adjust the input to a function-like
> type?  Any other examples?
>
> I use fmap all the time, but I've never used contramap, so I'm curious
> if I'm missing something useful.
>
> On Wed, Sep 13, 2017 at 10:33 AM, Siddhanathan Shanmugam
> <siddhanathan+eml at gmail.com> wrote:
> > 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-
> 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/
> docs/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
> >>
> >
> >
> > _______________________________________________
> > 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/9a6a2b39/attachment.html>