[Haskell-cafe] A question about "monad laws"

[Richard A. O'Keefe]

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.