For me, mostly naming. Cofunctor isn&#39;t the right name for it, and comap, while short, feels wrong. Contrafunctor feels better but is also cumbersome. No problems with Comonad, though.<br><br><div class="gmail_quote">On Thu, Dec 23, 2010 at 9:16 PM, Mario Blažević <span dir="ltr">&lt;<a href="mailto:mblazevic@stilo.com">mblazevic@stilo.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br><div class="gmail_quote">On Thu, Dec 23, 2010 at 5:25 PM, Stephen Tetley <span dir="ltr">&lt;<a href="mailto:stephen.tetley@gmail.com" target="_blank">stephen.tetley@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div>On 23 December 2010 21:43, Mario Blažević &lt;<a href="mailto:mblazevic@stilo.com" target="_blank">mblazevic@stilo.com</a>&gt; wrote:<br>
&gt; Why are Cofunctor and Comonad classes not a part of the base library?<br>
</div>[SNIP]<br>
<div>&gt; Later on I found that this question has been raised before by Conal Elliott,<br>
&gt; nearly four years ago.<br>
&gt;<br>
&gt; <a href="http://www.haskell.org/pipermail/libraries/2007-January/006740.html" target="_blank">http://www.haskell.org/pipermail/libraries/2007-January/006740.html</a><br>
<br>
<br>
</div>From a somewhat &quot;philistine&quot; persepective, that Conal&#39;s question went<br>
unanswered says something:<br>
<br>
&quot;Does anyone have useful functionality to go into a Cofunctor module<br>
(beyond the class declaration)?&quot;<br>
<br>
Successful post-H98 additions to Base (Applicative, Arrows, ...)<br>
brought a compelling programming style with them. For Comonads,<br>
Category-extras does define some extra combinators but otherwise they<br>
have perhaps seemed uncompelling.<br>
</blockquote></div><br><br></div>There are plenty of potential Cofunctor instances on Hackage, as I&#39;ve pointed out. The other side of the proof of the utility of the class would be to find existing libraries that could be parameterized by an arbitrary functor: in other words, some examples in Hackage of<br>

<br>&gt; class Cofunctor c =&gt; ...<br>&gt; instance Cofunctor c =&gt; ...<br>&gt; f :: Cofunctor c =&gt; ...<br><br>This would be rather difficult to prove - such signatures cannot be declared today, and deciding if existing declarations could be generalized in this way would require a pretty deep analysis. The only thing I can say is &quot;build it and they will come&quot;.<br>

<br>To turn the proof obligation around, what could possibly be the downside of adding a puny Cofunctor class to the base library?<br><br>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br>