Proposal: New Eq and Ord instances for Double and Float

[Simon Marlow]

On 11/11/2011 14:02, Roman Leshchinskiy wrote:
> Twan van Laarhoven wrote:
>> On 10/11/11 18:03, Roman Leshchinskiy wrote:
>>> Oh, I never said it would be easy :-) But this definitely seems like the
>>> right thing to do to me.
>>>
>>> In the context of this thread, however, it would be perfectly acceptable
>>> if NaNs just aborted the program. The original problem was that they
>>> mess
>>> up things. It is implementation-defined what happens if a computation
>>> wants to create a NaN. We could simply say that the program is aborted
>>> by
>>> default, with a way to turn off this behaviour and just create a NaN.
>>> Raising a Haskell exception would certainly be very nice but not
>>> essential
>>> for this particular problem.
>>
>> That seems dangerous. This is what happens now if I use unchecked div
>> for example:
>>
>>       $ ghci
>>       Prelude>  GHC.Base.divInt 1 0
>>       Floating point exception
>>       $
>
> One could argue that this is a bug in ghci - perhaps it shouldn't abort if
> evaluating an expression causes an error.

GHC.Base.divInt is an unsafe function, in the same way that unsafeCoerce 
is: you can crash the program by using it in the wrong way.  Maybe it 
should be called unsafeDivInt, but this isn't a user-visible API, so we 
don't really care.

>> It exits ghci immediately. Having "0/0" crash would make trusting 'safe'
>> programs much harder. For example, I could no longer make an IRC bot for
>> evaluating numeric expressions, and expect it to keep running.
>
> You could by explicitly enabling silent NaNs and handling them specially.
> The original problem was that we currently silently generates NaNs which
> have surprising semantics if you aren't specifically dealing with them.
> This problem is solved by having NaNs abort the program and having a way
> to recover the current behaviour.
>
> Again, having a Haskell exception would be vastly preferable but as a
> short-term solution, aborting the program seems acceptable to me.

I'm surprised to hear you say that - aborting the program is *never* 
acceptable behaviour as far as I'm concerned, unless the API is 
explicitly labelled "unsafe" and you use it in an unsafe way.  Even the 
rare places in Haskell where behaviour is explicitly undefined never 
abort the program in GHC.

It would be a shame if any module using division were not allowed to be 
classed as "safe" by SafeHaskell.

Cheers,
	Simon