First off, -0.0 =:= 0.0 coming out true is a BUG.
It’s simply wrong behaviour.
It is also a clear and blatant BUG that 0.0 = -0.0
succeeds.
Erlang CAN distinguish these two numbers and DOES
distinguish them. (Most obviously in term_to_binary/1
and float_to_list/1, but there are others.)
It makes NO sense to appeal to the IEEE standard for
floating-point arithmetic in a programming language
that goes out of its way NOT to conform to that standard.
Not just omitting IEEE operations such as copysign(-,-)
– and there is no shortage of other missing operations –
but also in omitting IEEE-mandated required values.
The facth that arithmetic comparison unifies 0.0, -0.0,
and 0 is no reason why “exact equality” should do so,
and certainly we’d have to regard any so-called total
order on terms that made (or, right now, makes)
T1 =:= T2,
F(T1) =/= F(T2)
come out true when F is a pure function, as badly broken.
As missing half the POINT of “equality”. As making it
harder to write correct code, for no advantage.
Arithmetic comparison SHOULD identify 0, 0.0, and -0.0
Exact comparison and matching should NOT.
Consider this.
f(X, X) → X.
f(0.0, -0.0).
Will the answer be 0.0 or -0.0? Can you tell which without
trying it? Is it obvious to you that it depends on the
order of the arguments? Is clause matching supposed to
depend on the order of the arguments?