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