G'day all.
Quoting Adrian Hey <[EMAIL PROTECTED]>:
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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
