I just got started learning Haskell a few days ago. I've implemented a numeric data type that can represent some irrational numbers exactly, and I'd like to instantiate the RealFrac class so I can do truncate, round, etc., in the most natural way in the language. Implementing properFraction (which is in RealFrac) would not a problem at all, but implementing RealFrac requires implementing Real, which has the function toRational, which Haskell 98 says "returns the rational equivalent of its real argument with full precision" which isn't possible for this number type (which includes irrationals). I'd also like to implement approxRational since this can be done in a straightforward manner with my data type, but this appears to be just a library function in the Ratio library and not a function defined in a class, and is dependent on the toRational function which doesn't make sense for a data type that can represent irrational values exactly. So my questions are: 1) Am I understanding the Haskell numeric classes correctly by thinking that to define properFraction I also have to define (incorrectly in this case) the toRational function? 2) Is a literal reading of Haskell 98 necessary for toRational or can it just be approximate? (Seems like not, since there's approxRational, and no other way to indicate the desired accuracy for toRational.) 3) If I'm right about toRational requiring "full precision", why was implementing this made a requirement for implementing properFraction? 4) Why on earth is there a class called "Real" that requires the ability to convert to Rational with full precision, which can't be done with all real numbers? As an example, consider a data type that can represent a quadratic surd, e.g. (1, 5, 2) might mean (1 + (sqrt 5)) / 2. With this data type it's straightforward to implement the Num and Fractional classes and get full arithmetic operations +, -, *, /, etc. The properFraction function also makes sense: there's an integer portion equal to 1 in this case, and a fractional portion equal to (-1, 5, 2), exactly. So truncate, round, ceiling, and floor make sense (in RealFrac). But toRational can't be implemented with "full precision". With this example you can also see how approxRational is a perfectly good idea, and would be something likely to be needed, but this function isn't a class function designed to be implemented by custom data types. It seems to me (with my meager few days of Haskell experience) that approxRational should have been part of the Real class, and that toRational should be relegated the Ratio library instead. Or else, that the functions that are in RealFrac should be in the Fractional class instead. So I'm guessing there are some good reasons for having RealFrac in addition to Fractional that I'm not yet aware of. -- View this message in context: http://www.nabble.com/Why-does-the-class-called-%22Real%22-support-only-rati... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.