Proposal: Bring the Contravariant class to base

[Daniel Díaz Casanueva]

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

[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.

Post by Daniel Díaz Casanueva
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Tony Morris]

FWIW, this is due to an earlier mistake, where it was named CoFunctor.
It has since been corrected to Contravariant, but the misnomer still
hangs around a little.

Contravariant is very similar to Functor (some people call it CoFunctor)

[Edward Kmett]

I'd be open to merging the existing Data.Functor.Contravariant module into
base (inverting dependencies as needed), while leaving the remainder of the
contravariant package intact. This module contains the class and a couple
of example contravariant functors, much in the same vein as Data.Monoid.
This would leave the more exotic machinery for 'contravariant applicatives'
and all the generic programming bits in the package.

+1

This would be similar to the migration of Data.Proxy from tagged into base,
which left behind Data.Tagged or the migration of Data.Semigroup from
semigroups, which left behind the generics module.

Almost all of the dependencies that would have inversions are packages I
maintain personally. The only package that would require coordination with
another maintainer would be inverting the instances for data types supplied
by transformers.

If there was a sufficient call for it, I'd be open to moving the rest into
base, but I don't anticipate a great deal of demand and this could always
happen at a later date or as part of another proposal, should this change.

-Edward

On Tue, Sep 12, 2017 at 11:44 PM, Daniel Díaz Casanueva <

Post by Daniel Díaz Casanueva
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Dmitry Olshansky]

Maybe `cmap` is better name than `contramap` here?

Post by Edward Kmett
I'd be open to merging the existing Data.Functor.Contravariant module into
base (inverting dependencies as needed), while leaving the remainder of the
contravariant package intact. This module contains the class and a couple
of example contravariant functors, much in the same vein as Data.Monoid.
This would leave the more exotic machinery for 'contravariant applicatives'
and all the generic programming bits in the package.
+1
This would be similar to the migration of Data.Proxy from tagged into
base, which left behind Data.Tagged or the migration of Data.Semigroup from
semigroups, which left behind the generics module.
Almost all of the dependencies that would have inversions are packages I
maintain personally. The only package that would require coordination with
another maintainer would be inverting the instances for data types supplied
by transformers.
If there was a sufficient call for it, I'd be open to moving the rest into
base, but I don't anticipate a great deal of demand and this could always
happen at a later date or as part of another proposal, should this change.
-Edward
On Tue, Sep 12, 2017 at 11:44 PM, Daniel Díaz Casanueva <

Post by Daniel Díaz Casanueva
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Andrew Martin]

I think changing the name would break all of the packages that already use it. That doesn't seem worth it to me.

Sent from my iPhone

Post by Dmitry Olshansky
Maybe `cmap` is better name than `contramap` here?

I'd be open to merging the existing Data.Functor.Contravariant module into base (inverting dependencies as needed), while leaving the remainder of the contravariant package intact. This module contains the class and a couple of example contravariant functors, much in the same vein as Data.Monoid. This would leave the more exotic machinery for 'contravariant applicatives' and all the generic programming bits in the package.
+1
This would be similar to the migration of Data.Proxy from tagged into base, which left behind Data.Tagged or the migration of Data.Semigroup from semigroups, which left behind the generics module.
Almost all of the dependencies that would have inversions are packages I maintain personally. The only package that would require coordination with another maintainer would be inverting the instances for data types supplied by transformers.
If there was a sufficient call for it, I'd be open to moving the rest into base, but I don't anticipate a great deal of demand and this could always happen at a later date or as part of another proposal, should this change.
-Edward

Post by Daniel Díaz Casanueva
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Dmitry Olshansky]

This is the best moment to do this (if it worth) when migrate to base
because of the name in the original package will not be changed.

But the name is not so important for me though. I just wanted to emphasize
such a possibility.

I think that names in base could be more concise than in other packages.

Post by Andrew Martin
I think changing the name would break all of the packages that already use
it. That doesn't seem worth it to me.
Sent from my iPhone
Maybe `cmap` is better name than `contramap` here?

Post by Edward Kmett
I'd be open to merging the existing Data.Functor.Contravariant module
into base (inverting dependencies as needed), while leaving the remainder
of the contravariant package intact. This module contains the class and a
couple of example contravariant functors, much in the same vein as
Data.Monoid. This would leave the more exotic machinery for 'contravariant
applicatives' and all the generic programming bits in the package.
+1
This would be similar to the migration of Data.Proxy from tagged into
base, which left behind Data.Tagged or the migration of Data.Semigroup from
semigroups, which left behind the generics module.
Almost all of the dependencies that would have inversions are packages I
maintain personally. The only package that would require coordination with
another maintainer would be inverting the instances for data types supplied
by transformers.
If there was a sufficient call for it, I'd be open to moving the rest
into base, but I don't anticipate a great deal of demand and this could
always happen at a later date or as part of another proposal, should this
change.
-Edward
On Tue, Sep 12, 2017 at 11:44 PM, Daniel Díaz Casanueva <

Post by Daniel Díaz Casanueva
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Edward Kmett]

Random bike shedding on module migration generally leads to a very slow migration process with no good user story for how to perform the move. Every bad experience I've encountered due to this process has come from some well-intentioned change like this. Users get hung up on how to perform the move, then incompatible package bounds abound.

I for one am pretty strongly -1 on bike shedding the module contents during the move.

contramap has had a few years to settle into users' consciousness and it helps drive home the fact that a contravariant functor is not a "cofunctor" (cofunctor = functor!) a common mistake among newbie category theorists that leads to all sorts of other misconceptions, like why isn't a comonad a "cofunctor" which cmap leaves notationally ambiguous.

-Edward



Sent from my iPhone

This is the best moment to do this (if it worth) when migrate to base because of the name in the original package will not be changed.
But the name is not so important for me though. I just wanted to emphasize such a possibility.
I think that names in base could be more concise than in other packages.

Post by Andrew Martin
I think changing the name would break all of the packages that already use it. That doesn't seem worth it to me.
Sent from my iPhone

Post by Dmitry Olshansky
Maybe `cmap` is better name than `contramap` here?

I'd be open to merging the existing Data.Functor.Contravariant module into base (inverting dependencies as needed), while leaving the remainder of the contravariant package intact. This module contains the class and a couple of example contravariant functors, much in the same vein as Data.Monoid. This would leave the more exotic machinery for 'contravariant applicatives' and all the generic programming bits in the package.
+1
This would be similar to the migration of Data.Proxy from tagged into base, which left behind Data.Tagged or the migration of Data.Semigroup from semigroups, which left behind the generics module.
Almost all of the dependencies that would have inversions are packages I maintain personally. The only package that would require coordination with another maintainer would be inverting the instances for data types supplied by transformers.
If there was a sufficient call for it, I'd be open to moving the rest into base, but I don't anticipate a great deal of demand and this could always happen at a later date or as part of another proposal, should this change.
-Edward

Post by Daniel Díaz Casanueva
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Oliver Charles]

I'd be +1 on this, and I'd actually be +1 on bringing in Divisible and
Decidable. The API very nicely provides a dual to the entire
Functor/Applicative/Alternative hierarchy, which is useful for parsing -
Contravariant/Divisible/Decidable is good for the opposite, that is -
serializing on pretty printing.
https://hackage.haskell.org/package/hasql-0.19.18.1/docs/Hasql-Encoders.html
for an example of a Decidable functor in the wild, is one example.

Post by Edward Kmett
Random bike shedding on module migration generally leads to a very slow
migration process with no good user story for how to perform the move.
Every bad experience I've encountered due to this process has come from
some well-intentioned change like this. Users get hung up on how to perform
the move, then incompatible package bounds abound.
I for one am pretty strongly -1 on bike shedding the module contents during the move.
contramap has had a few years to settle into users' consciousness and it
helps drive home the fact that a contravariant functor is not a "cofunctor"
(cofunctor = functor!) a common mistake among newbie category theorists
that leads to all sorts of other misconceptions, like why isn't a comonad a
"cofunctor" which cmap leaves notationally ambiguous.
-Edward
Sent from my iPhone
This is the best moment to do this (if it worth) when migrate to base
because of the name in the original package will not be changed.
But the name is not so important for me though. I just wanted to emphasize
such a possibility.
I think that names in base could be more concise than in other packages.

Post by Andrew Martin
I think changing the name would break all of the packages that already
use it. That doesn't seem worth it to me.
Sent from my iPhone
Maybe `cmap` is better name than `contramap` here?

Post by Edward Kmett
I'd be open to merging the existing Data.Functor.Contravariant module
into base (inverting dependencies as needed), while leaving the remainder
of the contravariant package intact. This module contains the class and a
couple of example contravariant functors, much in the same vein as
Data.Monoid. This would leave the more exotic machinery for 'contravariant
applicatives' and all the generic programming bits in the package.
+1
This would be similar to the migration of Data.Proxy from tagged into
base, which left behind Data.Tagged or the migration of Data.Semigroup from
semigroups, which left behind the generics module.
Almost all of the dependencies that would have inversions are packages I
maintain personally. The only package that would require coordination with
another maintainer would be inverting the instances for data types supplied
by transformers.
If there was a sufficient call for it, I'd be open to moving the rest
into base, but I don't anticipate a great deal of demand and this could
always happen at a later date or as part of another proposal, should this
change.
-Edward
On Tue, Sep 12, 2017 at 11:44 PM, Daniel Díaz Casanueva <

Post by Daniel Díaz Casanueva
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Bardur Arantsson]

Post by Edward Kmett
Random bike shedding on module migration generally leads to a very slow
migration process with no good user story for how to perform the move.
 Every bad experience I've encountered due to this process has come from
some well-intentioned change like this. Users get hung up on how to
perform the move, then incompatible package bounds abound.
I for one am pretty strongly -1 on bike shedding the module contents during the move.
contramap has had a few years to settle into users' consciousness and it
helps drive home the fact that a contravariant functor is not a
"cofunctor" (cofunctor = functor!) a common mistake among newbie
category theorists that leads to all sorts of other misconceptions, like
why isn't a comonad a "cofunctor" which cmap leaves notationally ambiguous.

+1 for the "minimal migration" you suggested.

-1000 on bikeshedding this. Even disregarding your good argument for
"contramap" vs. "cmap": the mere dropping of 5 letters is not *ever*
going to be significant in the grand scheme of things.

Regards,

[Andrew Martin]

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 <

Post by Daniel Díaz Casanueva
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Aloïs Cochard]

Hi there,

Just to say I'm all for it as well, wanted that in base a few time in the
past...

Cheers

Post by Andrew Martin
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 <

Post by Daniel Díaz Casanueva
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Siddhanathan Shanmugam]

I find Contravariant functors to be a nice abstraction. +1 on this.

- Sid

Post by Aloïs Cochard
Hi there,
Just to say I'm all for it as well, wanted that in base a few time in the
past...
Cheers

Post by Andrew Martin
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-Cont
ravariant-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 <

Post by Daniel Díaz Casanueva
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

--
*Λ\oïs*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Evan Laforge]

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

Post by Siddhanathan Shanmugam
I find Contravariant functors to be a nice abstraction. +1 on this.
- Sid

Post by Aloïs Cochard
Hi there,
Just to say I'm all for it as well, wanted that in base a few time in the
past...
Cheers

Post by Andrew Martin
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

Post by Daniel Díaz Casanueva
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

--
Λ\oïs
http://twitter.com/aloiscochard
http://github.com/aloiscochard
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Siddhanathan Shanmugam]

are there any articles out there discussing what contramap is good for?

There are some examples in this article:
https://ocharles.org.uk/blog/guest-posts/2013-12-21-24-days-of-hackage-contravariant.html

-- Sid

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

Post by Siddhanathan Shanmugam
I find Contravariant functors to be a nice abstraction. +1 on this.
- Sid

Post by Aloïs Cochard
Hi there,
Just to say I'm all for it as well, wanted that in base a few time in

the

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard
past...
Cheers

Post by Andrew Martin
I am +1 on this. Like others, I also only want
Data.Functor.Contravariant, not the rest of the machinery in there. As

a

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin
historical data point, I proposed this a year ago
(http://haskell.1045720.n5.nabble.com/Move-Data-Functor-

Contravariant-into-base-td5847730.html),

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin
but the we ended up on a tangent why a DeriveContravariant wouldn't

really

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin
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

Post by Daniel Díaz Casanueva
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]

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
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

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
simple, very basic class, that would receive better and greater use if
included in base. Contravariant is very similar to Functor (some

people call

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
it CoFunctor), but in `contramap` (Contravariant's `fmap`) the

"arrow" of

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
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

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
(although personally I don't think that is a real problem). The
contravariant package itself provides a plentiful of instances, many

of them

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
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

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
not included in aeson because either it was not desired to add the
contravariant package as dependency, or simply because Contravariant

is not

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
so well-known. Note that, however, `FromJSONKeyFunction` _is_

instance of

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
Functor. Even though both instances are equally natural and useful in

this

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
context, only one of them was implemented. This probably would not

have

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
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

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
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

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

--
Λ\oïs
http://twitter.com/aloiscochard
http://github.com/aloiscochard
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[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

Post by Evan Laforge
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

Post by Siddhanathan Shanmugam
I find Contravariant functors to be a nice abstraction. +1 on this.
- Sid

Post by Aloïs Cochard
Hi there,
Just to say I'm all for it as well, wanted that in base a few time in

the

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard
past...
Cheers

Post by Andrew Martin
I am +1 on this. Like others, I also only want
Data.Functor.Contravariant, not the rest of the machinery in there. As

a

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin
historical data point, I proposed this a year ago
(http://haskell.1045720.n5.nabble.com/Move-Data-Functor-

Contravariant-into-base-td5847730.html),

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin
but the we ended up on a tangent why a DeriveContravariant wouldn't

really

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin
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

Post by Daniel Díaz Casanueva
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]

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
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

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
simple, very basic class, that would receive better and greater use if
included in base. Contravariant is very similar to Functor (some

people call

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
it CoFunctor), but in `contramap` (Contravariant's `fmap`) the

"arrow" of

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
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

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
(although personally I don't think that is a real problem). The
contravariant package itself provides a plentiful of instances, many

of them

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
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

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
not included in aeson because either it was not desired to add the
contravariant package as dependency, or simply because Contravariant

is not

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
so well-known. Note that, however, `FromJSONKeyFunction` _is_

instance of

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
Functor. Even though both instances are equally natural and useful in

this

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
context, only one of them was implemented. This probably would not

have

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
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

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
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

Post by Siddhanathan Shanmugam

Post by Aloïs Cochard

Post by Andrew Martin

Post by Daniel Díaz Casanueva
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

--
Λ\oïs
http://twitter.com/aloiscochard
http://github.com/aloiscochard
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[John Wiegley]

MS> Also: +1 for including in base.

Another +1 here.