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
