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