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

[ajb at spamcop.net]

G'day all.

Quoting Adrian Hey <ahey at iee.org>:

> I take it you mean something like ..

Err... yes, I did.

> Where's the Eq instance for OrdWrap?

Omitted for brevity.

> This may or may not satisfy
> the law: (compare a b) = EQ implies (a == b) = True. I think
> everbody agrees about that, but I can't tell from the code
> you've posted if it does in this case.

The default implementation of compare says that.

One thing that's not explicitly stated in the report is whether or not
the instances of typeclasses like Eq or Ord need to "do the same thing
as"[*] the default implementations.  Does x /= y "do the same thing as"
not (x == y)?

> What's disputed is whether or not this law should hold:
>  (a == b) = True implies a = b

Apart from possibly your good self, I don't think this is disputed.
Quotient types, as noted elsewhere in this thread, are very useful.
Their common use predates Miranda, so it's way too late to unbless
them now.

> Well I hope you or anyone else hasn't used Data.Map or with OrdWrap
> keys because if so it's likely that the code has either been broken in
> the past, or is broken now (not sure which).

For Data.Map, using an OrdWrap-like wrapper for keys is wrong, because
it's not necessary.  OrdWrap is for situations where you need to
associate a value with a key which is, unsurprisingly, what Data.Map
also does.

As for sort, the behaviour hasn't been broken at any point in the past
or present that I'm aware of, and a lot of people would strongly resist
it if it ever were proposed that it be broken.

Cheers,
Andrew Bromage

   [*]  "Do the same thing as" here means that they mean the
        same thing, but allows for the possibility that some
        implementation may be less stack-consuming, lazier or
        in some way more efficient than its default.