[Haskell-cafe] Re: (flawed?) benchmark : sort

[Aaron Denney]

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
-><-