On 12 Feb 2008, at 10:35 am, David Benbennick wrote:
Some months ago I pointed out that Ratio Int (which is an Ord instance) doesn't satisfy this property. I provided a patch to fix the problem, but my bug report was closed as wontfix: http://hackage.haskell.org/trac/ghc/ticket/1517.
I'm not happy about that response. Basically, if the inputs to a mathematical operation are representable, and the mathematically correct result is representable, I expect a system to deliver it or die trying. What the intermediate calculations get up to is the implementor's problem, not the user's. On the other hand, if I knew in advance whether a particular + or * was going to overflow, I probably wouldn't need the computer to actually do it. But if I give the computer some numbers that are clearly representable and just ask it to *sort* them, it had better d--- well get that RIGHT. I am extremely grateful for this report, because now I know "NEVER USE Ratio Int, it's too broken". Sad aside: back in the 70s I had my own Ratio Int written in Burroughs Algol. I was not smart enough to use double precision numbers for anything, but because of one hardware feature, it didn't matter a lot. That hardware feature was that integer overflows were TRAPPED and REPORTED. I have since used precisely one C compiler on precisely one Unix system that took advantage of the fact that the C standard (both C89 and C99) was very carefully written to ALLOW TRAPPING of signed integer overflows. (Contrary to mythology, C only requires wrapping for unsigned integers.) I found that a surprisingly valuable debugging aid. This all supports the general point, of course: data types whose operations are so implemented as to break sensible laws can and WILL land you in great piles of fresh steaming hot fertiliser.