On Sunday 25 September 2011, 23:13:47, Chris Smith wrote:
Don't mix range and arithmetic sequences. I want arithmetic sequences for Double, Float and Rational, but not range. (For Float and Double one could implement range [all values between the given bounds, in increasing order, would be the desired/expected semantics for that, I think?],
Okay, fine, I tried. Obviously, I'm opposed to just flat removing features from the language, especially when they are so useful that they are being used without any difficulty at all by the 12 year olds I'm teaching right now.
Agreed. But If we want a change to remove a wart, we should try to remove it completely. We can still settle for "make it smaller" if it doesn't work out.
Someone (sorry, not me) should really write up the proposed change to Ord for Float/Double
Okay.
and shepherd them through the haskell-prime process.
Uh oh. I ope that can be done with a libraries proposal. (Ian says yes :-D)
That one shouldn't even be controversial; there's already an isNaN people should be using for NaN checks, and any code relying on the current behavior is for all intents and purposes broken anyway. The only question is whether to add the new methods to RealFloat (breaking on the bizarre off chance that someone has written a nonstandard RealFloat instance), or add a new IEEE type class.
Add to RealFloat, default to the Eq/Ord functions, I'd say. But that's not the only question. Is -0.0 == 0.0 or not? I lean towards no because of 1/x, but I'm not wedded to that. And: distinguish NaNs or identify them all? I lean towards identifying them all, I've never cared for whether they come from 0/0, Infinity - Infinity or what, but I could be convinced.