On Aug 24, 2008, at 8:10 PM, Mark S. Miller wrote:
> On Sun, Aug 24, 2008 at 7:54 PM, Brendan Eich <[EMAIL PROTECTED]>
> 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.
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
