I've been thinking about the following type class design principles:
* Only include two functions in the same design class if both can be implemented in terms of each other.
* Only introduce a dependency from type class A to type class B if all functions in type class B can be implemented in terms of the functions in type class A or if type class A is empty.
One of the other well-known type class inconveniences is the Num type class. The major inconvenience is that abs and signum are in the same type class as (+), (*), fromInteger etc, since within mathematics there are many structures on which the latter can be defined but not the former. The minor inconvenience is that (+) and (*) are in the same type class, since on occasion one wants an instance which defines one but not the other. I would also say that the Eq, Show constraints on Num are unwarranted. So to get to the point, I guess I would say that another design principle (perhaps a looser version of your first) is - don't put things together in a type class if they can be understood as separate concepts Unfortunately it is very hard, if not impossible, to get existing type classes changed, due to the amount of code that now depends on them. I have been thinking for a while that it might be worth defining a Prelude2, which corrects the known problems with the Prelude. Over time, people could migrate to using Prelude2. It would probably take years to be widely adopted, but at least there would be light at the end of the tunnel.