Yitzchak Gale
+1 on removing the Show constraint. I abstain on the Eq constraint - either way is fine with me.
Jon Fairbairn wrote:
But pattern matching for Double or Float is a Bad Thing, so wouldn’t the solution to this be to put the EQ constraint somewhere else, such as Integral where it would be less improper?
The Badness comes from the Eq instance itself. Once that instance exists, using it for pattern matching isn't any worse than equating with a Num literal in an expression. If we are going to have an Eq constraint at all, it might as well be on Num.
I don’t see the logic of that. The problem is that having an Eq constraint on Num forces people to give Eq instances for types that do not naturally have them, such as Real types. Certainly there’s little difference between using (==) and pattern matching, but the issue was that removing the Eq constraint from Num would make programmes that test equality (either way) on integers require the programmer to add “Eq t => …” somewhere in a programme that previously didn’t require it. Moving the Eq constraint to Integral would mean that programmers declaring instances would only be required to add Eq when making something an instance of Integral, a class that one would naturally expect to have equality, while programmers simply using Integer or Int &c would need to make no change (and programmers using pattern matching on Double would get the error they deserve). -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk