[Haskell-cafe] Re: Why purely in haskell?

Cristian Baboi writes after my long political speech on numerics:

Well, Haskell has this "referential transparency" thing which say that a function is a function and you will never be able to build anything else :-)

What do you want to say/claim/suggest/propose/deny?? All these speculations about NaN==NaN, and other disgraceful exceptions don't convey anything which would really break the referential transparency, unless you outlaw yourself. Travesting a US military saying: If 'em things are not comparable, don't! We can formalize this attitude, e.g. by extending/modifying the Num (and the Eq and Ord) classes to take into account the specificity of the non-standard arithmetic, but in general this contains plenty of traps. It will be eventually done, but perhaps not tomorrow... Ketil Malde reacts to:

...

The bombing of NaN *might* be a profound compilation option, but for people who really do numerical work, this is a blessing NOT to have it.

I don't understand this. Are you worried users will edit the language pragmas in your code, and complain about NaN errors?

I do not worry about anything. I signal that the philosophy of crashing the program as soon as an exceptional number is created (or even used), is not the only one possible.

Back when I *was* using the abbreviation FP for 'Floatin Point', I often got NaNs due to programming errors. Given the NaN's nature of contaminating subsequent results, getting an exception at the first occurrence would aid in tracking it down.

...

- Ignoring Int overflow is a cheap way of having `mod` (MAXINT+1). Useful for many purposes.

...and ditto for this. The usefulness of one case in no way justifies sabotagin all other cases.

As I said, the exceptional treatment of exceptional values might be a compilation option, as it was in some Fortrans I used long time ago. You want your programs to react histerically to all difficulties in math, since you are afraid of propagating NaNs, etc. And *then* you will have to sit down and correct your code. If there is no exception, your program may run happily, and produce rubbish, yes? I am more conservative. If you are afraid of rubbish, protect your code by appropriate checks *before* the errors occur. What you call a "sabotage" I call the programmers negligence. You say that the usage of NaN as "empty" is a <>. I presume you want to say "Nothing". In a sense yes, but not "poor man". It is a way of admitting that we have a hidden extended type, Nums, and other stuff, such as NaNs and infinities. Floating-point numbers seem not to be a *one* pure, primitive type, but a variant one. The problem is that this new type values may come out of computations on normal values, so the static type system of Haskell *in its actual shape* seems to be a bit too weak. Instead of making a mess with the existing structures, please, propose a non-standard Num class, and the appropriate instancing, which distinguish between normal, and anormal numbers. Be free to bomb, or to react silently to exceptional values. The difference between you (and/or Wolfgang J.) and myself is that I enjoy more my freedom, even if I have to pay with a little more work. You want to enforce rigid reactions of the system. You should be free to do it on *your* machine, not on mine. Jerzy Karczmarczuk