#4019: deriving Ord can produce incorrect and inefficient instances
---------------------------------+------------------------------------------
Reporter: rl | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.13
Keywords: | Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
Patch: 0 |
---------------------------------+------------------------------------------
Comment(by rl):
You are quite right, these are two separate issues. I originally thought
that they are symptoms of the same problem but this is obviously not the
case.
With respect to efficiency, ideally automatically derived Ord methods
would use appropriate comparison operators instead of compare for
comparing the last field of a constructor. That is, deriving Ord should
generate this:
{{{
(a,b) > (c,d) = case compare a c of
GT -> True
EQ -> b > d -- instead of compare b d == GT
LT -> False
}}}
But perhaps this is too minor (although if would be interesting to find
out if this has a measurable effect on nofib).
As to correctness, IEEE floating point comparisons simply aren't a total
ordering. I don't know what to do here, either, but I think this is more
of a language definition problem than a GHC issue. For the moment, I would
perhaps simply say that comparisons involving !NaNs produce unspecified
results (i.e., it is an unchecked precondition of compare and friends that
they aren't applied to a !NaN).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4019#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
