On 2008-03-13, Adrian Hey <ahey at iee.org> wrote:
> 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
-><-