Brian Boutel <[EMAIL PROTECTED]> writes:
>> 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
_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
