Proposal: Bring the Contravariant class to base

Fri Sep 15 09:35:10 UTC 2017

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.

On Fri, Sep 15, 2017 at 1:01 AM, Edward Kmett <ekmett at gmail.com> wrote:

> 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
> On Sep 14, 2017, at 3:23 PM, Dmitry Olshansky <olshanskydr at gmail.com>
> wrote:
>
> 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.
>
> 2017-09-14 15:35 GMT+03:00 Andrew Martin <andrew.thaddeus at gmail.com>:
>
>> 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
>>
>> On Sep 14, 2017, at 5:39 AM, Dmitry Olshansky <olshanskydr at gmail.com>
>> wrote:
>>
>> Maybe `cmap` is better name than `contramap` here?
>>
>> 2017-09-13 16:02 GMT+03:00 Edward Kmett <ekmett at gmail.com>:
>>
>>> 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 <
>>> 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/doc
>>>> s/Data-Functor-Contravariant.html#t:Contravariant
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> 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/20170915/cf273532/attachment-0001.html>