On 2008-03-13, Adrian Hey
But the trouble is the report says practically *nothing* about Eq class or what the (==) operator means. It all seems to be assumed, and even when it does talk about it informally it talks about "equality", not "equivalence" or some other word.
The report doesn't state that for all Ints, (x==y = True) implies that x=y.
No, it doesn't. However, for Ints, it's the most reasonable natural (and generic) definition. The report should be clarified on this point.
There's no reason to suppose the Int instance is in any way special,
Well, what do you mean by "special"? That it has this additional guarantee? I don't see that as unusual for Eq instances, no. In fact, I expect typical Eq instances to satisfy this. However, if all I know is Eq a, I don't think it can be counted on, so it is special in that sense. Just as, say Maybe a, along with many, or even most other common Monads might satisfy more laws than a generic Monad a, doesn't necessarily make it special. But you can't still write generic Monad code assuming these other properties. Instead, you require MonadPlus instances, or similar for whatever additional properties you need.
so do you really seriously consider the possibility that this might not hold in your Int related code?
if (x==y) then f x else g x y
might not mean the same as..
if (x==y) then f y else g x y
In Int code, of course not, because I know the types, and I know the behaviour of (==) on Ints. But f is specialized to work on Ints, isn't it, so it's reasonable to know what semantics (==) has for Ints, and depend on them? -- Aaron Denney -><-