I'm still not happy with adding more incompleteness into something that intuitively feels safe - compare is pretty benign. Having a crash on division is something that does appeal to me more. Are you suggesting that 0.0/0.0 should crash also? I'm no expert, but
Neil Mitchell wrote: think returning a NaN is according to the floating point standard (IEEE 754), and I'm not convinced Haskell should break that. If you use floating point, you need to know the pitfalls anyway. Maybe comparing NaNs should give random results? :-) The bad thing is that comparison can hide the NaNs (for arithmetic, NaNs will be contagious, so you'll likely get a NaN riddled output). One thing I remember seeing (from Fortran compilers?) is that when a program execution involves a NaN, it is reported on termination, even if the NaN was in an intermediate calculation and not part of the final result. Something like that could perhaps be useful if the current behavior is kept? -k