Brian Boutel
The fact that equality can be trivially defined as bottom does not imply that it should be a superclass of Num, it only explains that there is an ugly way of working around the problem.
There is nothing trivial or ugly about a definition that reflects reality and bottoms only where equality is undefined.
I think there is. If I design a class and derive it from Num with (==) is bottom, I am allowed to apply to it functions requiring a Num argument, but I have no guarantee it will work. The implementor of that function can change its internals (to use (==)), and suddenly my previously working program is non-terminating. If I defined (==) to give a run time error, it'd be a bit better, but I'd much prefer the compiler to tell me about this in advance.
Of course, if you do not need to apply equality to your "numeric" type then having to define it is a waste of time, but consider this:
It's not about "needing to apply", but about finding a reasonable definition.
- Having a class hierarchy at all (or making any design decision) implies compromise.
I think the argument is that we should move Eq and Show *out* of the Num hierarchy. Less hierarchy - less compromise.
- The current hierarchy (and its predecessors) represent a reasonable compromise that meets most needs.
Obviously a lot of people seem to think we could find compromises that are more reasonable.
- Users have a choice: either work within the class hierarchy and accept the pain of having to define things you don't need in order to get the things that come for free,
Isn't it a good idea to reduce the amount of pain?
or omit the instance declarations and work outside the hierarchy. In that case you will not be able to use the overloaded operator symbols of the class, but that is just a matter of concrete syntax, and ultimately unimportant.
I don't think syntax is unimportant. -kzm -- If I haven't seen further, it is by standing in the footprints of giants