<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ůvodní zpráva --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Předmě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ák <a class="moz-txt-link-rfc2396E" href="mailto:petr.mvd@gmail.com"><petr.mvd@gmail.com></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"><ekmett@gmail.com></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"><schlepptop@henning-thielemann.de></a>, Frantisek Farka
<a class="moz-txt-link-rfc2396E" href="mailto:ffarka@gmail.com"><ffarka@gmail.com></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> class Functor f => Applicative f</div>
<div> gives one way to automatically define fmap</div>
<div><br>
</div>
<div> class Functor f => Traversable f</div>
<div> gives another way to define fmap for free</div>
<div><br>
</div>
<div> class Functor f => Comonad f</div>
<div> 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 => 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>
Best regards,<br>
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ák <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:petr.mvd@gmail.com" target="_blank">petr.mvd@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 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>
Best regards,<br>
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.
<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"><<a
moz-do-not-send="true"
href="mailto:schlepptop@henning-thielemann.de"
target="_blank">schlepptop@henning-thielemann.de</a>></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) =>
(s -> (a, s)) -> s -> t a<br>
unfoldr = evalState . sequenceA . pure .
state<br>
<br>
One could state a law like:<br>
<br>
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>