jerzy.karczmarczuk@info.unicaen.fr writes:
People, you are monsters.
Well, bring on the torches and the pitchforks (although the image in my mind is more like a mob carrying lenses and bananas).
no, some users are victims of its success as a formal language, not just as a coding tool
I think Haskell's theoretical basis is part of its success as a coding tool.
... They *want* to have Eq as they imagine the equality, including the comparison between incomparable.
In an ideal world, yes, but I think the monster to which you respond was fairly clear on being 'practical' here?
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? 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. I'd wager Ints see wider use in settings where the silent 'mod' is harmful, than where this effect is desired. Again, the current behavior causes errors that are very hard to track down. IMHO, these are two very different types, and I'm sligtly baffled that the fact is not reflected in Haskell. -k -- If I haven't seen further, it is by standing in the footprints of giants