On 2008-03-13, Adrian Hey
Aaron Denney wrote:
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?
Why are Ints special in this way? Couldn't you use say exacly the same about any type (just substitute type "X" of your choice for "Int")
About any /type/, yes. When I'm writing code specific to type X, I can be expected to know more about the type than what guarantees a generic type inhabiting the same type classes will have. In fact, I better know more, because I'm calling specialized functions that take X, rather than a, or Eq a => a. If I didn't, I'd be writing a more or less generic function, that could operate on more types than X. But this doesn't hold for any old use of (==), or compare. The function sort (to go back to the beginning of this thread) as a generic function, need not assume /anything/ about observation equality to sort a list. All it needs do is use the comparison function on the elements to reorder them. This makes it /more useful/ than one that gets cute by duplicating elements that compare equal, because it can be used in more situations. -- Aaron Denney -><-