<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I forgot to add "libraries" as a recipient, so I'm forwarding the
    mail.<br>
    PP<br>
    <div class="moz-forward-container"><br>
      -------- P&#367;vodn&iacute; zpr&aacute;va --------
      <table class="moz-email-headers-table" border="0" cellpadding="0"
        cellspacing="0">
        <tbody>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">P&#345;edm&#283;t:
            </th>
            <td>Re: Pointed and Traversable</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Datum: </th>
            <td>Fri, 30 Aug 2013 16:59:45 +0200</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Od: </th>
            <td>Petr Pudl&aacute;k <a class="moz-txt-link-rfc2396E" href="mailto:petr.mvd@gmail.com">&lt;petr.mvd@gmail.com&gt;</a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Komu: </th>
            <td>Edward Kmett <a class="moz-txt-link-rfc2396E" href="mailto:ekmett@gmail.com">&lt;ekmett@gmail.com&gt;</a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Kopie: </th>
            <td>Henning Thielemann
              <a class="moz-txt-link-rfc2396E" href="mailto:schlepptop@henning-thielemann.de">&lt;schlepptop@henning-thielemann.de&gt;</a>, Frantisek Farka
              <a class="moz-txt-link-rfc2396E" href="mailto:ffarka@gmail.com">&lt;ffarka@gmail.com&gt;</a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">Dne 08/26/2013 10:26 PM, Edward Kmett
        napsal(a):<br>
      </div>
      <blockquote
cite="mid:CAJumaK-yXY2RFDTg3xbi4zD=dq3x0VaM2uh+XS9zN9w0XBpwDg@mail.gmail.com"
        type="cite">
        <div dir="ltr">I can't speak well to SHE's implementation but
          there are a few tensions in the design space of how to handle
          default superclass instances in a language like Haskell that
          makes them not perfectly solve the issue that Haskell
          generally sucks at dealing with deep accurate typeclass
          hierarchies.<br>
          <div><br>
          </div>
          <div>1.) When you have a complex lattice of types rather than
            a linear chain, you're going to get a lot of ways to derive
            the common default functionality.</div>
          <div><br>
          </div>
          <div>&nbsp;class Functor f =&gt; Applicative f</div>
          <div>&nbsp; &nbsp; gives one way to automatically define fmap</div>
          <div><br>
          </div>
          <div>&nbsp;class Functor f =&gt; Traversable f</div>
          <div>&nbsp; &nbsp;gives another way to define fmap for free</div>
          <div><br>
          </div>
          <div>&nbsp;class Functor f =&gt; Comonad f</div>
          <div>&nbsp; &nbsp;gives a third way to define fmap for free</div>
          <div><br>
          </div>
          <div>In general when you have a lattice of properties points
            above you in the lattice will start getting an exploding
            number of definitions from classes below them, leading to
            limited utility for any 'hiding' based mechanism as you've
            traded n definitions for n hiding declarations. <br>
          </div>
        </div>
      </blockquote>
      True, that's an important issue to solve, I'll have to think about
      it. One idea that emerges is to borrow some concepts from OOP/Java
      and to distinguish "interface"-like type classes that have no
      defaults (just the ones we have now) and "class"-like type classes
      that can have defaults. And "class"-like could "descend" only from
      at most one other "class"-like type class. (This is perhaps
      somewhat similar to <a moz-do-not-send="true"
        class="moz-txt-link-freetext"
        href="http://repetae.net/recent/out/classalias.html">http://repetae.net/recent/out/classalias.html</a>,
      which distinguishes classes from class aliases.)<br>
      <br>
      <blockquote
cite="mid:CAJumaK-yXY2RFDTg3xbi4zD=dq3x0VaM2uh+XS9zN9w0XBpwDg@mail.gmail.com"
        type="cite">
        <div dir="ltr">
          <div><br>
          </div>
          <div>2.) As typeclass hierarchies become deeper with more
            refined notions, say, Functor, Semiapplicative, Semimonad,
            Pointed, Applicative, Monad (note the last 2 only have laws
            with no methods in the perfect world), you wind up being
            able to get fewer default/mutual definitions to work at any
            individual level of the hierarchy.</div>
          <div><br>
          </div>
          <div>3) Product-like constructions, monad transformers, etc.
            still need definitions for every point in the typeclass
            lattice. Since almost all of my code is polymorphic in this
            style, it turns out I almost never get to use the instances
            that would be supplied by a default superclass system.</div>
        </div>
      </blockquote>
      <br>
      Could you please give an example? You mean that if let's say we
      introduce Applicative =&gt; Monad with the default superclass
      system, you'd still have to refactor your code?<br>
      <br>
      <blockquote
cite="mid:CAJumaK-yXY2RFDTg3xbi4zD=dq3x0VaM2uh+XS9zN9w0XBpwDg@mail.gmail.com"
        type="cite">
        <div dir="ltr">
          <div><br>
          </div>
          <div>I generally favor the notion of adding default
            definitions for superclass methods and adding 'default
            instances', I just think it is necessary to point out that
            it doesn't help nearly as much as everyone thinks it will,
            when it comes to the pains induced by retroactively adding a
            finer grained inheritance hierarchy.</div>
          <div><br>
          </div>
          <div>Culturally, it is a hard sell to the average Haskeller to
            get them to embrace a class that doesn't give them any new
            methods, so we wind up with an awkward culture that favors a
            few powerful abstractions over the full menagerie of
            accurate types.</div>
        </div>
      </blockquote>
      I'd say it depends how it's presented. The main selling point for
      adding fine grained hierarchy is that more things get a common
      type class. Like we could say we don't need Functors or
      Applicatives because most of them are Monads anyway, but still
      people agree that Functors are useful and needed. So I think the
      main objection of the average Haskeller is that introducing a new
      type class breaks (his) stuff. If we can find a mechanism how to
      avoid that, I'd say (s)he wouldn't mind (perhaps even care).<br>
      <br>
      &nbsp; Best regards,<br>
      &nbsp; Petr<br>
      <br>
      <blockquote
cite="mid:CAJumaK-yXY2RFDTg3xbi4zD=dq3x0VaM2uh+XS9zN9w0XBpwDg@mail.gmail.com"
        type="cite">
        <div dir="ltr">
          <div><br>
          </div>
          <div>-Edward</div>
          <div><br>
          </div>
        </div>
        <div class="gmail_extra"><br>
          <br>
          <div class="gmail_quote">On Mon, Aug 26, 2013 at 2:18 PM, Petr
            Pudl&aacute;k <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:petr.mvd@gmail.com" target="_blank">petr.mvd@gmail.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 bgcolor="#FFFFFF" text="#000000">
                <div>One of our students is currently exploring how to
                  extend Haskell so that splitting classes into more
                  fine-grained hierarchy won't cause these problems:<br>
                  <a moz-do-not-send="true"
href="https://groups.google.com/forum/#%21topic/haskell-cafe/W1NbrikzgCQ"
                    target="_blank">https://groups.google.com/forum/#!topic/haskell-cafe/W1NbrikzgCQ</a><br>
                  along the lines of<br>
                  <a moz-do-not-send="true"
                    href="http://ghc.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances"
                    target="_blank">http://ghc.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances</a><br>
                  Unfortunately, it seems his message went unnoticed by
                  Haskell community.<br>
                  <br>
                  &nbsp; Best regards,<br>
                  &nbsp; Petr Pudlak<br>
                  <br>
                  Dne 08/26/2013 07:16 PM, Edward Kmett napsal(a):<br>
                </div>
                <div>
                  <div class="h5">
                    <blockquote type="cite">
                      <div dir="ltr">There are several uses of Pointed
                        as a separate beast from Applicative. In
                        particular it comes up when we talk about
                        "affine traversals", and would let us refine the
                        type hierarchy of lens, so you'd think I'd be
                        for it.&nbsp;
                        <div> <br>
                        </div>
                        <div>However, to move it into its own class
                          would require literally everyone who currently
                          has an Applicative instance to clutter their
                          code with CPPs.
                          <div><br>
                          </div>
                          <div>Even as the author of the Pointed class,
                            I personally find that the benefit of the
                            change doesn't warrant the impact of the
                            change.</div>
                          <div><br>
                          </div>
                          <div>-Edward</div>
                        </div>
                      </div>
                      <div class="gmail_extra"><br>
                        <br>
                        <div class="gmail_quote">On Mon, Aug 26, 2013 at
                          12:59 PM, Henning Thielemann <span dir="ltr">&lt;<a
                              moz-do-not-send="true"
                              href="mailto:schlepptop@henning-thielemann.de"
                              target="_blank">schlepptop@henning-thielemann.de</a>&gt;</span>
                          wrote:<br>
                          <blockquote class="gmail_quote"
                            style="margin:0 0 0 .8ex;border-left:1px
                            #ccc solid;padding-left:1ex">There was a lot
                            of discussion about separating "pure" from
                            Applicative and putting it into a Pointed
                            class. If I remember correctly, the main
                            counter argument was that 'pure' alone does
                            not satisfy interesting laws. There are only
                            such laws in connection with the Applicative
                            class.<br>
                            <br>
                            Now, in some situations I liked to have a
                            generalized unfoldr. I can build this from
                            "pure" and "sequenceA" using the State
                            monad:<br>
                            <br>
                            unfoldr :: (Pointed t, Traversable t) =&gt;
                            (s -&gt; (a, s)) -&gt; s -&gt; t a<br>
                            unfoldr = evalState . sequenceA . pure .
                            state<br>
                            <br>
                            One could state a law like:<br>
                            <br>
                            &nbsp; &nbsp;traverse f (pure a) == traverse id (pure
                            (f a))<br>
                            <br>
                            Would this justify to move "pure" into a new
                            Pointed class?<br>
                            <br>
_______________________________________________<br>
                            Libraries mailing list<br>
                            <a moz-do-not-send="true"
                              href="mailto:Libraries@haskell.org"
                              target="_blank">Libraries@haskell.org</a><br>
                            <a moz-do-not-send="true"
                              href="http://www.haskell.org/mailman/listinfo/libraries"
                              target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
                          </blockquote>
                        </div>
                        <br>
                      </div>
                      <br>
                      <fieldset></fieldset>
                      <br>
                      <pre>_______________________________________________
Libraries mailing list
<a moz-do-not-send="true" href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>
<a moz-do-not-send="true" href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a>
</pre>
                    </blockquote>
                    <br>
                  </div>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </blockquote>
      <br>
      <br>
    </div>
    <br>
  </body>
</html>