Es-discuss - several decimal discussions

Brendan Eich brendan at
Sun Aug 24 23:01:31 PDT 2008

On Aug 24, 2008, at 8:10 PM, Mark S. Miller wrote:

> On Sun, Aug 24, 2008 at 7:54 PM, Brendan Eich <brendan at>  
> 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.

First bullet:

       (typeof x == typeof y && x == y) iff x === y

I'm suggesting that we could specify that 1.0m === 1.00m, which of  
course implies 1.0m == 1.0m, and vice versa.

Yes, it's independent of what typeof 1.0m returns. My point about  
typeof was the one I just made to Sam: that since -0 == 0, we have  
wiggle room that does not yet exist for object types. But I think we  
can wiggle our way to === equating distinct object identities  
(cohorts in P754 terms), just as we do for the numbers -0 and 0.

Indistinguishability is already "broken" for -0 and 0 (you can use  
Math.atan2 to discern) and NaN (irreflexive). What's the big deal if  
we go further? I smell purity trumping usability. Again I do not see  
a compelling case for adding eq, solely based on this Decimal conundrum.

It seems to me I've seen this kind of arguing before. "Pay no  
attention to the impurity behind the curtain, or in front of it!  
Assume purity and use it to justify further generalizations." I'm not  
in favor without more real-world evidence. Impurity of JS functions  
as imperfect lambdas, or of == among like types as less than the  
ideal indistinguishability equivalent relation, matters.

>> 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.
> Object.eq isn't about numbers or strings, so that's not an adequate
> coping strategy.

That's circular. The coping strategy is for Decimal users who really  
want to distinguish inside a cohort. It's not (yet, or universally)  
necessary to have Object.eq for all values. The hashtable idea is  
good but it just needs funargs with sane defaults. There will  
probably be many such collection implementations.


More information about the Es-discuss mailing list