On 2008-03-13, Adrian Hey <[EMAIL PROTECTED]> 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 -><- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe