# Es-discuss - several decimal discussions

Brendan Eich brendan at mozilla.org
Sun Aug 24 19:54:44 PDT 2008

```On Aug 24, 2008, at 7:41 PM, Mark S. Miller wrote:

> On Sun, Aug 24, 2008 at 7:01 PM, Brendan Eich <brendan at mozilla.org>
> wrote:
>> You're assuming 1.0m === 1.00m must be true. I'm disputing that (see
>> exchange with Sam, who may agree).
>
> Indeed. One of the ES3.1 phone calls characterized the two early
> positions as
> * The typeof school: ES3 currently has the regularity
>       (typeof x == typeof y && x == y) iff x === y
>   Let's not break that regularity. It's a good idea, and existing code
> may count on it.

Right.

> * The eq school: ES3 currently has the regularities that
>        except for NaN, === is an equivalence relation
>        for all x,y except for -0, x === y implies x is observably
> indistinguishable for y
>    Let's not break those regularities. It's a good idea, and existing
> code may count on it.

Yup.

> 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?

>> 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....

>> We can enlarge the language to be
>> strictly more expressive, or we could enlarge equivalence classes
>> under ===,
>> or we could choose to make certain seemingly equal numbers !==. The
>> rationale for excluding the last two alternatives when mooting
>> Object.eq is
>> not clear.
>
> Re second alternative: don't you mean "shrink equivalence classes",
> ideally to singletons, ignoring {-0, 0}?

No, that would be the third alternative, where 1.0m !== 1.00m. I mean
enlarge as in 1.0m === 1.00m means that {1.0m, 1.00m, ...} is an
equivalence class. This is the current ES3.1 draft spec's position
(hope I have that right!). IOW, each infamous cohort from P754
becomes an equivalence class.

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.

/be

```