Refactoring Semigroup/Monoid (was: instance Applicative Data.Map)

[Edward Kmett]

Honestly, the main issue is that even if you have the ability to describe
default definitions for how to implement superclasses, it isn't really all
that useful. :(

e.g. Every monad transformer still needs each of its instances crafted by
hand. This even applies to simpler types:

Given

instance (Traversable f, Traversable g) => Traversable (Compose f g)

you don't want the derived instances for Functor and Foldable,

instance (Traversable f, Traversable g) => Functor (Compose f g)
instance (Traversable f, Traversable g) => Foldable (Compose f g)

you want the more permissive ones you can roll by hand.

instance (Functor f, Functor g) => Functor (Compose f g)
instance (Functor f, Functor g) => Foldable (Compose f g)

or

newtype Const a b = Const a

where

instance Functor (Const a)

isn't the superclass default you'd get from

instance Monoid m => Applicative (Const m)

We've held up any sort of serious reform of the class hierarchy because we
keep hoping that some kind of solution to this problem will swoop in and
save us.

This is one of those situations where the hope for a better solution being
'right around the corner' for the last few years has crippled our resolve
to proceed with the things we _could_ fix.

I'm pessimistic enough not to see how progress can be made.

In the absence of the silver bullet that I don't think* **can* exist,
"wiser" heads will continue to prevail and I'll continue to have to
implement most of my combinators 2 or more times to deal with Monad vs.
Applicative, etc, cluttering my namespaces and duplicating effort.

This is one area where a more traditional OOP language has a serious
benefit over Haskell. It is far easier to retroactively add levels to a C++
class hierarchy without breaking any code, than it is to add them to a
Haskell class hierarchy at all.

-Edward

On Sat, Nov 17, 2012 at 10:06 AM, Dan Burton <danburton.email at gmail.com>wrote:

> Adding new superclasses breaks a lot of code for little gain for most
>> people. We need a technical solution to this problem first, before we can
>> refactor our type hierarchy.
>
>
> A technical solution, eh?
>
> http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
>
> What is the status on this? How hard would this be to implement as a GHC
> extension? Are there any reasons this should not be baked into, say,
> Haskell 2014?
>
> -- Dan Burton
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121117/7766561b/attachment.htm>