Move Data.Functor.Contravariant into base
Andrew Martin
andrew.thaddeus at gmail.com
Sun Dec 11 22:10:24 UTC 2016
That's a good point about the deriving ambiguity. I had not really
thought that through all the way. Additionally, I just stumbled across
https://github.com/ekmett/contravariant/issues/17, which makes it pretty
clear that there actually isn't a good way to handle all cases. I think
that it might still be nice to have a DeriveContravariant that is simply
weaker than DeriveFunctor. It could just complain and error out in
ambiguous cases. The ambiguous cases would be all types parameterized
by more than one higher-kinded type. And DeriveFunctor could just be
left alone, continuing to derive the Functor instance for Compose the
same way it already does. Usually, when I write Contravariant instances,
it's for stuff like this that doesn't even involve anything
higher-kinded:
data Encoding c a = Encoding (Vector (c, a -> c))
Of course, I could be totally wrong about the rule I suggested for
figuring out ambiguous cases. I guess I probably need to think about it
more. Regardless, I'm glad to hear that someone else is in favor of moving
Contravariant into base.
On Sun, Dec 11, 2016 at 12:05:05PM -0800, Shachaf Ben-Kiki wrote:
> Putting Contravariant in base sounds like a reasonable thing to do.
> It's a pretty basic class.
>
> Deriving Contravariant seems a bit tricky. If Contravariant is in base
> and part of the deriving code, what Functor/Contravariant instances do
> you derive for e.g. newtype Compose f g a = Compose (f (g a))?
>
> Shachaf
>
> On Sun, Dec 11, 2016 at 8:14 AM, Andrew Martin
> <andrew.thaddeus at gmail.com> wrote:
> > The typeclass Contravariant (from the contravariant package) is both
> > useful and fundamental. I would like to see this moved into base.
> > One additional motivating factor is that it would become possible
> > for a DeriveContravariant extension to be written in a future GHC
> > release. I'd love to hear other people's thoughts, even if it's as
> > simple as a yea or nay. Thanks.
> >
> > -Andrew Martin
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
More information about the Libraries
mailing list