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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe