<div dir="ltr">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. <a href="https://hackage.haskell.org/package/hasql-0.19.18.1/docs/Hasql-Encoders.html">https://hackage.haskell.org/package/hasql-0.19.18.1/docs/Hasql-Encoders.html</a> for an example of a Decidable functor in the wild, is one example.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 15, 2017 at 1:01 AM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>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.</div><div><br></div><div>I for one am pretty strongly -1 on bike shedding the module contents during the move.</div><div><br></div><div>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.</div><div><br>-Edward</div><div><br><div><br><br>Sent from my iPhone</div><div><div class="h5">On Sep 14, 2017, at 3:23 PM, Dmitry Olshansky <<a href="mailto:olshanskydr@gmail.com" target="_blank">olshanskydr@gmail.com</a>> wrote:<br><br></div></div></div><div><div class="h5"><blockquote type="cite"><div><div dir="ltr">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.<div><br></div><div>But the name is not so important for me though. I just wanted to emphasize such a possibility.</div><div><br></div><div>I think that names in base could be more concise than in other packages.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-09-14 15:35 GMT+03:00 Andrew Martin <span dir="ltr"><<a href="mailto:andrew.thaddeus@gmail.com" target="_blank">andrew.thaddeus@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I think changing the name would break all of the packages that already use it. That doesn't seem worth it to me.<br><br>Sent from my iPhone</div><div><div class="m_-5193474482836387391h5"><div><br>On Sep 14, 2017, at 5:39 AM, Dmitry Olshansky <<a href="mailto:olshanskydr@gmail.com" target="_blank">olshanskydr@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Maybe `cmap` is better name than `contramap` here? </div><div class="gmail_extra"><br><div class="gmail_quote">2017-09-13 16:02 GMT+03:00 Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div><div>+1</div></div><div><br></div><div>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.<div><div><br></div></div><div>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.<div><div><br></div><div>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.</div><span class="m_-5193474482836387391m_1195032845258597110HOEnZb"><font color="#888888"><div><br></div><div>-Edward</div></font></span></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-5193474482836387391m_1195032845258597110h5">On Tue, Sep 12, 2017 at 11:44 PM, Daniel Díaz Casanueva <span dir="ltr"><<a href="mailto:dhelta.diaz@gmail.com" target="_blank">dhelta.diaz@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-5193474482836387391m_1195032845258597110h5"><div dir="ltr">Dear haskellers,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>In a real world scenario I had, it was very useful to add a Contravariant instance to `Data.Aeson.ToJSONKeyFunction`<wbr>, 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.</div><div><br></div><div>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.</div><div><br></div><div>Best regards,</div><div>Daniel Casanueva</div><div><br></div><div># References</div><div><br></div><div>[1] <a href="http://hackage.haskell.org/package/contravariant-1.4/docs/Data-Functor-Contravariant.html#t:Contravariant" target="_blank">http://hackage.haskell.org<wbr>/package/contravariant-1.4/doc<wbr>s/Data-Functor-Contravariant.h<wbr>tml#t:Contravariant</a></div></div>
<br></div></div><span>______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
<br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>Libraries mailing list</span><br><span><a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a></span><br><span><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a></span><br></div></blockquote></div></div></div></blockquote></div><br></div>
</div></blockquote></div></div></div><br>______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>