jerzy.karczmarczuk@info.unicaen.fr writes:
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.
You are putting words in my mouth! I do not want to enforce rigid reactions on the system, I want the option to enforce them on my programs.
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.
*I* proposed a compile-time option, *you* responded that it is a "blessing NOT to have it".
You want your programs to react histerically to all difficulties in math, since you are afraid of propagating NaNs, etc.
If you consider halting execution to be a hysterical reaction, arithmetic errors to be all difficulties in math, and wishing for accurate error messages to be afraid, I guess the answer is 'yes'.
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?
Yes.
I am more conservative. If you are afraid of rubbish, protect your code by appropriate checks *before* the errors occur.
I've written a bit of checking code in my time. The problem is that you quickly end up with more checking code than 'real' code, that the checking code paths are rarely used, and thus even more bug prone than the rest of the code, and that usually, there is little you can sensibly do other than halt execution anyway. The nice thing about checking for integer overflow and arithmetic exception is that they can be added with no cost in code size or complexity, and (at least on some architectures) no cost in performance - perhaps even improvements, for signaling NaNs. My Haskell programs tend to be rather Spartan, and I think this makes them more readable, and thus more likely to actually be correct.
What you call a "sabotage"
I.e. the insistence on wrap-around Ints (a minority use case!) and quiet NaNs as the One True Way, disallowing all other approaches.
I call the programmers negligence.
I'll pleade guilty to the charge of being negiligent and not checking intermediate results for errors and overflows. But the only reason for using Int (and not Integer) and arguably floating point, is performance. Wrapping everything in checks will be laborious, and I am fairly certain that performance will suffer by magnitudes. So yes, I am lazy, I use Int and cross my fingers. (I'm not alone; I've read a fair bit of Haskell code (starting with the Prelude), I must just have been unfortunate to miss all the code written by the industrious and serious people who actually check their Int operations...) -k -- If I haven't seen further, it is by standing in the footprints of giants