Re: Remove Enum from Float and Double

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