Proposal: Bring the Contravariant class to base

[Artyom]

I am +1 on this, though I am −0.1 on merging `contravariant` into `base`
fully.

Note that I am biased because a) I am generally in favor of
significantly bigger `base` than we have today, and b) it would let me
bring `Getter` (from lens) to `microlens`, which I rather want to do.

By the way, I think Edward Kmett had some good arguments about why
`Profunctor` shouldn't be in `base`, but I don't remember whether those
arguments apply to `Contravariant` or not.

On 09/13/2017 12:44 AM, Daniel Díaz Casanueva 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170913/15546172/attachment.html>