# Es-discuss - several decimal discussions

Mark S. Miller erights at google.com
Sun Aug 24 20:10:15 PDT 2008

```On Sun, Aug 24, 2008 at 7:54 PM, Brendan Eich <brendan at mozilla.org> wrote:
>> If === remains as good an indistinguishability test as it is now --
>> with only the above two exceptions -- then I'd agree we don't need
>> Object.eq. Libraries could provide it without undue burden. However,
>> assuming you agree that 1.0m == 1.00m, then you'd break the regularity
>> in the first bullet.
>
> Does that not depend on what typeof 1.0m returns?

Huh? As long as typeof 1.0m == typeof 1.00m, then you'd still break
the first bullet.

>>> I'm trying to avoid too much creature feep in any edition ;-). Other
>>> languages have near-universally-quantified hashcode analogues but solve
>>> NaN
>>> dilemmas by throwing (Python, IIRC).
>>
>> FWIW, E has exactly two equality operators:
>>  * x == y implies observable equivalence, but operates more like
>> Henry Baker's EGAL operator than like Lisp's EQ.
>>       NaN == NaN // yields true
>>       -0.0 == 0.0 // yields false
>>  * x <=> y means "According to x, x and y are the same magnitude".
>>       NaN <=> NaN // yields false
>>       -0.0 <=> 0.0 // yields true
>
> Nice. No Decimal in E, though, with preserved significance....

Someone could add a decimal library to E without special dispensation
from the language designers. If one did, then I'd recommend they do it
such that

m`1.0` == m`1.00` // yields false
m`1.0` <=> m`1.00` // yields true

(The backquote syntax is E's way of embedding DSLs. The identifier to
the left of the backquote is mangled into a quasi-parser name, to
parse and evaluate the string between the quotes.
brings some similar ideas to JavaScript.)

> It seems to me that this second way was conflated with adding Object.eq,
> when it's not strictly necessary to add Object.eq if those who really need
> to distinguish significance of two otherwise equal decimals could reach for
> compareTotal or stringification and == or === and cope.