So why one might need it? I've never used Rational, but, if asked, I would say that they are for exact representation of numbers (some symbolic calcs). On the other side, 'real' dotted numbers always represent some real values with finite accuracy. That's look like a bad idea to me to call Rational numbers 'real' and type (print) them as a decimal fraction (*). Further, one would like to treat Rational as not just a decimal fraction, but, for example, decimal fraction with a period -- 0.12(3). I think that (readFloat :: ReadS Rational) must not be in Reported libs. I anybody wants, let him declare
instance RealFloat Rational,
taking all the responsibility. Muth better would be provide (maybe where is) a function
realToFrac :: RealFloat a, RealFrac b => a -> a -> b, realToFrac x err = ...
which would provide the shortest fractional approximation to a given 'real' number. Max. (*) Some school teachers like children to write solution of (4*x-3=0) as 0.75. I highly disagree with it. 3/4 is 3/4, but "0.75" is 0.75+-0.005 :) On Tuesday, 2002-05-28, 18:57, CEST Simon Peyton-Jones wrote:
Folks
I'm back to tidying up the Haskell Report.
In the Numeric library, there is the useful function
readFloat :: RealFloat a => ReadS a
But you can't use it for reading rationals, because Rational isn't in RealFloat!
This is a Royal Pain, and entirely unnecessary. In fact, readFloat uses only operations from the RealFrac class, so it could equally well have type
readFloat :: RealFrac a => ReadS a
I'm strongly inclined to make this change. It breaks no programs, and it fixes a real bug i.e. there is no way to read a "103" as a Rational.
Simon