I don't see much gain. It will break previously working code and the workaround to the breakage will likely be manually reimplementing enumFromTo in each instance.

As an aside, many years ago I did exactly that after being bit by Enum infelicities, and while you could say it's a reimplementation, in my opinion it's a better implementation: -- | Enumerate an inclusive range. Uses multiplication instead of successive -- addition to avoid loss of precision. -- -- Also it doesn't require an Enum instance. range :: (Num a, Ord a) => a -> a -> a -> [a] range start end step = go 0 where go i | step >= 0 && val > end = [] | step < 0 && val < end = [] | otherwise = val : go (i+1) where val = start + (i*step) -- | Enumerate a half-open range. range' :: (Num a, Ord a) => a -> a -> a -> [a] range' start end step = go 0 where go i | step >= 0 && val >= end = [] | step < 0 && val <= end = [] | otherwise = val : go (i+1) where val = start + (i*step) -- | Infinite range. range_ :: (Num a) => a -> a -> [a] range_ start step = go 0 where go i = start + (i*step) : go (i+1)

More to supply evidence in answer to your question than to present a point of view, the following is an example of code I wrote fairly recently: phi :: Double -> Double -> Complex Double phi x y = sum [ exp((-pi * (x + n)^2) :+ (2 * pi * n * y)) | n <- [-100..100] ] I wouldn't claim for a second that this is good style, but the point is that I don't actually care in this instance whether I gain or lose one or two terms in the sum (they're all vanishingly small by that point) so I think this is in some sense legitimate. I could of course take n as an integer, but in this rather cheap-and-dirty program I made a conscious trade-off in favour of readability and against lots of fromIntegral's. I don't have strong views either way as to whether the language should coerce me into being a better person in this sense, but my point is just that this proposal would break not-unreasonable code -- how much depending on how many people ever use Haskell for numerical work. Freddie On 11 June 2013 19:18, harry wrote:

Johan Tibell writes:

...

I don't see much gain. It will break previously working code and the workaround to the breakage will likely be manually reimplementing enumFromTo in each instance.

I forgot the main point of my post :-)

The primary motivation for removing these instances is that they cause endless confusion for beginners, e.g.

http://stackoverflow.com/questions/13203471/the-math-behind-1-09999999999999... , http://stackoverflow.com/questions/9810002/floating-point-list-generator, http://stackoverflow.com/questions/7290438/haskell-ranges-and-floats,

http://stackoverflow.com/questions/10328435/how-to-solve-floating-point-numb... , and many more.

On the other hand, how much working code is there "correctly" using there instances?

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

On Tue, Jun 11, 2013 at 2:18 PM, Johan Tibell wrote:

If we truly believe that the instance is dangerous for users (and not merely for people who don't understand floating point arithmetic on computers), then we should add a deprecation pragma to the instance and discourage its use. But what would the deprecation message encourage instead, for users to write an explicit loop that tests against some lower/upper bound? It would have the same problem as enumFromTo.

If the problem is increasing inaccuracy, then it likely wouldn't. E.g.:

last [0, 0.1 .. 20] 20.000000000000195 last (range 0 20 0.1) 20.0

On Tue, Jun 11, 2013 at 3:00 PM, Roman Cheplyaka wrote:

Does such thing as a deprecation pragma for an instance exist? What triggers it?

I don't know. We'll need one if we're going to deprecating core instances. Just deleting them is not an option (as it gives users with large code bases no time to migrate).

Johan Tibell writes:

If we truly believe that the instance is dangerous for users (and not merely for people who don't understand floating point arithmetic on computers), then we should add a deprecation pragma to the instance and discourage its use. But what would the deprecation message encourage instead, for users to write an explicit loop that tests against some lower/upper bound? It would have the same problem as enumFromTo. I think the issue here is really that floating point math on computers is hard to think about.

The issue is that these instances encourage problematic code. People who know what they're doing can write whatever they want, but we shouldn't be handing out unstable explosives on street corners :-)

Tillmann Rendel writes:

In general, I would be against removing features just because they are confusing for beginners. I don't think that's a good design principle for a language that is primarily targeted at professional programmers and computer scientists.

They're confusing to beginners because they don't have consistent or sensible semantics. That should bother the professional programmers and computer scientists too!