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

Henning Thielemann lemming at henning-thielemann.de
Sun Mar 17 21:11:19 CET 2013


On Sun, 17 Mar 2013, Roman Cheplyaka wrote:

> * Henning Thielemann <lemming at henning-thielemann.de> [2012-11-20 00:26:17+0100]
>>
>> On Sat, 17 Nov 2012, Edward Kmett wrote:
>>
>>> 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)
>>
>>
>> Good example. Frequently I think that we should replace all these
>> type class instance extensions by a generic way to program instances.
>
> What do you mean? Don't we already have TH and plenty of generic
> programming libraries?

That was last year, how shall I know today what I meant? :-) The various 
meta-programming utilites can be used to _implement_ type class instances. 
But I think there should be a way to unify all the UndecidableInstances, 
OverlappingInstances, FlexibleInstances, FlexibleContexts, 
TypeSynonymInstances, that is there might a programmable way to _select_ a 
class dictionary for some given concrete types.


More information about the Libraries mailing list