[Haskell-cafe] Re: pi

[jerzy.karczmarczuk at info.unicaen.fr]

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.