Re: [Haskell-cafe] Extending Type Classes

The problem of refinement of type classes annoys me from time to time when I work on the NumericPrelude. It is an experimental type class hierarchy for mathematical types. Sometimes a new data type T shall be implemented and it turns out that you can implement only a part of all methods of a certain class. Then a natural step is to split the class into two classes A and B: 'A' contains the methods we can implement for T and 'B' contains the remaining methods and 'B' is a sub-class of 'A'. First, this means that all client code has to be rewritten. Second, code for instances becomes very lengthy, because over the time code tends to contain one instances for every method. However the many small instances actually carry information: Every instance has its specialised constraints. E.g. you would certainly try to use only Applicative constraints in an Applicative instance and not Monad constraints. However, if there is a way to define Applicative and Monad instances in one go, the Applicative instance may get Monad constraints.

See http://ghc.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances | -----Original Message----- | From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf | Of Henning Thielemann | Sent: 26 August 2013 20:07 | To: Frantisek Farka | Cc: Haskell Cafe | Subject: Re: [Haskell-cafe] Extending Type Classes | | | The problem of refinement of type classes annoys me from time to time | when I work on the NumericPrelude. It is an experimental type class | hierarchy for mathematical types. Sometimes a new data type T shall be | implemented and it turns out that you can implement only a part of all | methods of a certain class. Then a natural step is to split the class | into | two classes A and B: 'A' contains the methods we can implement for T and | 'B' contains the remaining methods and 'B' is a sub-class of 'A'. | First, this means that all client code has to be rewritten. Second, | code | for instances becomes very lengthy, because over the time code tends to | contain one instances for every method. However the many small instances | actually carry information: Every instance has its specialised | constraints. E.g. you would certainly try to use only Applicative | constraints in an Applicative instance and not Monad constraints. | However, | if there is a way to define Applicative and Monad instances in one go, | the | Applicative instance may get Monad constraints. | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (2)
-
Henning Thielemann
-
Simon Peyton-Jones