Suppose you have a typeclass C with operations x y z w and you decide that there's a real difference, that more things can support x y than can support z w. If you then split C' x y C z w then all existing *uses* of C are happy. But all the existing *instances* of C have to be split into an instance for C' and an instance of C. Alternative is of course the example we're discussing, but this is a problem that's going to keep on coming up. Suggestion 1: If someone writes an instance declaration that says some type T is an instance of some class C, and there is a parent class C' for which the compiler can't find a declaration that T belongs to C', BUT all the operations needed for membership in C' are actually in the instance declaration for C, why can't the compiler automatically construct an instance declaration that T is an instance of C' and move the necessary definitions there? so instance (context) => C T where x = y = z = w = => instance (context) => C' T where x = y = instance (context) => C T where z = w = I dare say there are all sorts of things that could go wrong with this, but I am too dumb to see what they are. I hasten to add that I have no idea whether this could be extended to multiparameter type classes or not. Something like this would make the refactoring of C into C'+C pretty much painless; the compiler could warn about unfactored instance declarations so you could migrate gradually to the new structure, but it wouldn't break working code. Suggestion 2: Make it explicit. Have instance (context) => C T deriving C' T -- new feature where x = y = z = w = do the refactoring. This requires a one-line explicit change for each existing instance declaration, so there's *some* pain, but it's *less* pain than a complete manual refactoring, which you might need to do repeatedly while working out a design.