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

[Aaron Denney]

On 2008-03-13, Adrian Hey <ahey at iee.org> wrote:
> But the trouble is the report says practically *nothing* about Eq
> class or what the (==) operator means. It all seems to be assumed,
> and even when it does talk about it informally it talks about
> "equality", not "equivalence" or some other word.
>
> The report doesn't state that for all Ints, (x==y = True) implies that
> x=y.

No, it doesn't.  However, for Ints, it's the most reasonable natural
(and generic) definition.

The report should be clarified on this point.

> There's no reason to suppose the Int instance is in any way
> special,

Well, what do you mean by "special"?  That it has this additional
guarantee?  I don't see that as unusual for Eq instances, no.  In fact,
I expect typical Eq instances to satisfy this.  However, if all I know
is Eq a, I don't think it can be counted on, so it is special in that
sense.

Just as, say Maybe a, along with many, or even most other common Monads
might satisfy more laws than a generic Monad a, doesn't necessarily make
it special.  But you can't still write generic Monad code assuming these
other properties.  Instead, you require MonadPlus instances, or similar 
for whatever additional properties you need.

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

-- 
Aaron Denney
-><-