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

[Neil Mitchell]

Hi

>  We're talking about *semantic correctness*, not efficiency. If you
>  want to fine tune your code like this you shouldn't be relying
>  on overloaded general purpose function implementations. E.G. the
>  COrdering type used by AVL lib is one way to do this. This lets
>  a combining comparison chose which of two "equal" values is used
>  (and other things).

I would have thought:

sort x == sortBy compare x

was a reasonable property to have. But you are proposing that sort
should make assumptions on the compare function, which you can't even
state in Haskell, but sortBy should not. That seems suspicious...

I also know of a data type:

data Set xs = Set [xs]

where the Set constructor is all nicely hidden. If I define Set "ab"
to be equal to Set "ba", should the compiler burst into flames? If we
_require_ all Eq definitions to follow our very narrowly defined
notion of equality, then the question comes up why we permit people to
write Eq at all - why doesn't the compiler just do it for us, if there
is only one right answer.

Thanks

Neil