Proposal: New Eq and Ord instances for Double and Float
rl at cse.unsw.edu.au
Fri Nov 11 15:02:00 CET 2011
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
>> 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
>> 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
>> 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.
> 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.
More information about the Libraries