Es-discuss - several decimal discussions

Mark S. Miller erights at google.com
Sun Aug 24 19:41:20 PDT 2008


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

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. Were that the case, I would soften my normal
avoidance of == to "When you know you've got two numbers (e.g. after
typeof checks) and you want numeric equality, use ==. Otherwise,
always use ===." A problem with this softer stance is it makes it much
harder for JSLint-like tools to warn about uses of == that should be
avoided. Nevertheless, I would be happy with this resolution.


> 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


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

-- 
    Cheers,
    --MarkM


More information about the Es-discuss mailing list