I remember seeing this very discussion about pointed being disjoint from functor just recently on one of the various haskell mailing lists. But as for my opinion on it, because there&#39;s no real way of specifying any laws for pointed without functor. With functor and pointed, you can say that you expect fmap f . point == point . f, but point on its own gives you nothing to latch onto for behavior expectations.<br>
<br><div class="gmail_quote">On Fri, Dec 24, 2010 at 11:08 AM, 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><div></div><div class="h5"><div class="gmail_quote">On Fri, Dec 24, 2010 at 7:43 AM, Maciej Piechotka <span dir="ltr">&lt;<a href="mailto:uzytkownik2@gmail.com" target="_blank">uzytkownik2@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 Fri, 2010-12-24 at 05:36 -0500, Edward Kmett wrote:<br>
&gt;<br>
&gt; +1 for adding Comonads. As an aside, since Haskell doesn&#39;t have (nor<br>
&gt; could it have) coexponential objects, there is no &#39;missing&#39;<br>
&gt; Coapplicative concept that goes with it, so there can be no objection<br>
&gt; on the grounds of lack of symmetry even if the Functor =&gt; Applicative<br>
&gt; =&gt; Monad proposal goes through.<br>
<br>
</div>There is still potentially useful Copointed/CoPointed:<br>
<br>
class [Functor a =&gt;] CoPointed a where<br>
    copoint :: f a -&gt; a<br>
</blockquote></div><br><br></div></div>Why should Copointed, or Pointed for that matter, be a subclass of Functor? I don&#39;t see the point of arranging all possible classes into a single complete hierarchy. These single-method classes can stand on their own. Once you have them, it&#39;s easy to declare<br>

<br>&gt; class (Functor f, Pointed f) =&gt; Applicative f<br><br>and also<br><br>&gt; class (Foldable f, Pointed f) =&gt; Sequence f<br><br>or whatever.<div class="im"><br><br><br>On Fri, Dec 24, 2010 at 4:51 AM, 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 style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex" class="gmail_quote"><div>On 24 December 2010 02:16, Mario Blažević &lt;<a href="mailto:mblazevic@stilo.com" target="_blank">mblazevic@stilo.com</a>&gt; wrote:<br>


<br>
&gt; To turn the proof obligation around, what could possibly be the downside of<br>
&gt; adding a puny Cofunctor class to the base library?<br>
<br>
</div>Hi Mario<br><br>
For the record I&#39;m personally neutral on Cofunctor and on balance<br>
would like to see Comonad added to Base.<br><br>
My reservation is really at the &quot;meta-level&quot; - I suspect there are a<br>
lot of candidates for adding to Base if you want to Base to be<br>
systematic about &quot;modeling structures&quot;. </blockquote></div><div><br><br>There is a limited number of methods with up to N unconstrained arguments, combinatorics takes care of that.<br><br>class Foo (x :: *) where<br>

 method1 :: x                    -- default, mempty, minBound, maxBound<br> method2 :: x -&gt; x             -- succ, pred, negate<br> method3 :: x -&gt; x -&gt; x      -- mappend<br> method4 :: (x -&gt; x) -&gt; x    -- fix<br>

<br>class Cons (c :: * -&gt; *) where<br> method1 :: x -&gt; c x           -- return, pure<br> method2 :: c x -&gt; x           -- extract<br> method3 :: c (c x) -&gt; c x    -- join<br> method4 :: c x -&gt; c (c x)    -- duplicate<br>

 method5 :: c (c x) -&gt; x<br>

 method6 :: x -&gt; c (c x)<br> method7 :: x -&gt; c x -&gt; c x <br> method8 :: c x -&gt; c x -&gt; x<br> method9 :: (x -&gt; x) -&gt; c x -&gt; c x<br> method10 :: (x -&gt; y) -&gt; c x -&gt; c y  -- fmap<br> method11 :: (x -&gt; y) -&gt; c y -&gt; c x  -- contramap<br>

 method12 :: x -&gt; c y -&gt; c y<br> method13 :: x -&gt; c y -&gt; c x<br> method14 :: c x -&gt; c y -&gt; x<br> method15 :: c x -&gt; (x -&gt; c x) -&gt; c x<br> method16 :: c x -&gt; (x -&gt; c y) -&gt; c y  -- &gt;&gt;=<br>

 method17 :: c x -&gt; (c x -&gt; x) -&gt; c x<br> method18 :: c x -&gt; (c x -&gt; y) -&gt; c y  -- extend<br><br><br>I may have left something out, but all types above should be inhabited. I have omitted methods on constructors that can be defined on a plain type, such as mplus :: m a -&gt; m a -&gt; m a, which is a restriction of the type of mappend.<br>

<br>If one were to explore the design space systematically with no backward compatibility baggage, the best approach might be:<br><br>- declare each method in a class of its own, with no laws whatsoever,<br>- never declare two methods in a same class,<br>

- combine the primitive classes into bigger classes,<br>- restrict the bigger classes with laws.<br><br>The Pointed and Copointed classes above are two examples.<br></div><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>