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.

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.

class Functor f => Applicative f gives one way to automatically define fmap

class Functor f => Traversable f gives another way to define fmap for free

class Functor f => Comonad f gives a third way to define fmap for free

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. 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

I forgot to add "libraries" as a recipient, so I'm forwarding the mail. PP -------- Pu*vodní zpráva -------- Pr(edme(t: Re: Pointed and Traversable Datum: Fri, 30 Aug 2013 16:59:45 +0200 Od: Petr Pudlák Komu: Edward Kmett Kopie: Henning Thielemann , Frantisek Farka Dne 08/26/2013 10:26 PM, Edward Kmett napsal(a): 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 http://repetae.net/recent/out/classalias.html, which distinguishes classes from class aliases.)

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.

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.

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?

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.

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.

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). Best regards, Petr

-Edward

On Mon, Aug 26, 2013 at 2:18 PM, Petr Pudlák mailto:petr.mvd@gmail.com> wrote:

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: https://groups.google.com/forum/#!topic/haskell-cafe/W1NbrikzgCQ https://groups.google.com/forum/#%21topic/haskell-cafe/W1NbrikzgCQ along the lines of http://ghc.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances Unfortunately, it seems his message went unnoticed by Haskell community.

Best regards, Petr Pudlak

Dne 08/26/2013 07:16 PM, Edward Kmett napsal(a):

...

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.

However, to move it into its own class would require literally everyone who currently has an Applicative instance to clutter their code with CPPs.

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.

-Edward

On Mon, Aug 26, 2013 at 12:59 PM, Henning Thielemann mailto:schlepptop@henning-thielemann.de> wrote:

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.

Now, in some situations I liked to have a generalized unfoldr. I can build this from "pure" and "sequenceA" using the State monad:

unfoldr :: (Pointed t, Traversable t) => (s -> (a, s)) -> s -> t a unfoldr = evalState . sequenceA . pure . state

One could state a law like:

traverse f (pure a) == traverse id (pure (f a))

Would this justify to move "pure" into a new Pointed class?

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries