Simon Marlow wrote:
On 10/11/2011 16:28, Roman Leshchinskiy wrote:
Simon Marlow wrote:
On 27/09/2011 10:02, Roman Leshchinskiy wrote:
Colin Paul Adams wrote:
A quick google for signalling NaNs seems to suggest that on the x86 architecture, you have to set a flag to raise an exception when encountering signalling NaNs. Otherwise they are just treated as quiet NaNs. But you have to create the signalling NaNs manually. They are not created as a result of arithmetic operations.
IIRC, with the appropriate flags set, arithmetic operations throw exceptions instead of creating NaNs. You can't really create a signalling NaN in a register because as soon as you do, you get a signal.
But they don't throw a Haskell exception, they throw a processor exception which kills your whole program. If we want a Haskell exception to result from 0/0, we have to insert extra checking code, which I'm sure you won't like :-)
I would, of course, expect the RTS to convert the processor exception to a Haskell exception!
You have high expectations :-) I don't think it's possible to do that without some very low-level platform-specific and processor-specific hacking, which is why for example we have the current software test for divide-by-zero. You basically get a signal and have to grovel around in the thread's registers and stack to recover the situation, and the exception could be thrown from *anywhere*.
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. Roman