ChrisK writes:
Putting 'pi' in the same class as the trigonometric functions is good design.
If you wish so... But: Look, this is just a numeric constant. Would you like to have e, the Euler's constant, etc., as well, polluting the name space? What for?
Moving smoothly from single to double precision was much of the motivation to invent a mechanism like type classes in the first place.
Pardon? I think I remember the time when type classes have been introduced. The motivation you mention is not very visible, if at all... Actually, the numerical hierarchy was - as the French would say - "bricolée" with plenty of common sense, but without a decent methodology... The type classes is a splendid invention, much beyond any numerics. Besides, most people who *really* need FlP numerics use only the most precise available, the "single precision" stuff is becoming obsolete.
There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions.
The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base...
If you do not want 'pi' in a class named Floating then you have to move all the transcendental stuff with it.
I would survive without moving anything anywhere, I assure you.
If you do not want 'pi' in any class, then you cannot reasonably put any of the transcendental functions in a class. This would really degrade the API.
What?? But it is just a numerical constant, no need to put it into a class, and nothing to do with the type_classing of related functions. "e" is not std. defined, and it doesn't kill people who use exponentials. Jerzy Karczmarczuk PS. One of the US Army folklore slogans say: "if it's ain't broken, don't fix it." I would say: if what you need is one good exemplar, don't overload it. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
