Let programmers use floats when they have the performance analysis to justify it. Before then, it's just another kind of premature optimisation - and high level languages should be avoiding it.
I don't see how irrationals as floats is premature optimization. If you already know symbolic representation is going to blow up quickly and cause downstream headaches the measures you take are not premature. Though now I do wonder how the headaches stack up against the float headaches :-)
Don't get me wrong I like the idea of symbolic representation. It's just that in everyday use it seems very impractical to me. Granted, limited forms of it like the fractional type don't have the complexity problem. But in many cases things devolve to floats quickly anyway. The people that care can use libraries and deal with the complexity.
This is the definition of premature optimisation - not knowing the impact, you're suggesting a performance change anyways. The point is, for programmers that don't care, inefficiency is good enough.
It could, in certain circumstances.
> I don't see how irrationals as floats is premature optimization.
It is, when it is because “could” and not because “does”.
> If you already know symbolic representation is going to blow up quickly and cause downstream headaches the measures you take are not premature
Sure, if you know that's going to happen. When you do it because it might happen, or because it happens to be the language’s default representation of irrational (or even exact decimal, or in JS’s case exact integer) numbers, that's a different story.
* (/ 1 3)
1/3 ; result is a fraction
* PI
3.141592653589793d0
* (* 1/3 pi)
1.0471975511965976d0 ; fraction * fp -> fp
* 9999999999999999999999
9999999999999999999999 ;transparent support for bigints