Refactoring Semigroup/Monoid (was: instance Applicative Data.Map)
ekmett at gmail.com
Sat Nov 17 17:18:46 CET 2012
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:
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)
newtype Const a b = Const a
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
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.
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?
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries