Es-discuss - several decimal discussions

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Thu Sep 4 00:29:28 PDT 2008

```Brendan Eich wrote:
> On Sep 3, 2008, at 11:15 PM, David-Sarah Hopwood wrote:
>
>> In the absence of decimal, Object.eq is trivial to spec:
>>
>>    Object.eq(NaN, NaN) = true
>>    Object.eq(  0,  -0) = false
>>    Object.eq( -0,   0) = false
>>    Object.eq(  x,   y) = (x === y), otherwise.
>>
>> or to implement:
>>
>>    Object.eq = function (x, y) {
>>      if (x === y) {
>>        return x !== 0 || 1/x === 1/y;
>>      } else {
>>        return x !== x && y !== y;
>>      }
>>    };

[shorter, but less clear code snipped]

> My point was that Decimal doesn't make the case particularly strong,
> since you just need to add Decimal.compareTotal:
>
> Object.eq = function (x, y) {
>     if (x instanceof Decimal && y instanceof Decimal)
>         return Decimal.compareTotal(x, y) == 0;
>     return (x === y) ? x !== 0 || 1/x == 1/y : x !== x && y !== y;
> }

1. You can't do that in ES3.1 if Decimal is not in ES3.1. You'd have
to add "typeof Decimal !== 'undefined' &&" to the 'if' condition.
And then you'd be trying to anticipate a future spec, rather than
relying on an existing one.

2. This only accounts for Decimal, not for any other future types where
=== might not be an identity comparison.

3. It's not clear to me that this code is correct; at least not without
making assumptions about how === will work on mixed arguments that
have not yet been agreed. Will 1 === 1m be true (when decimals are
added)? If so, then Object.eq(1, 1m) as implemented above will be
true when it should be false.

> How much less trivial is this? Two lines, fewer with more ?: chaining.

The size of the code is irrelevant. Object.eq doesn't add significantly
to language complexity, and provides a useful basic operation, so why
shouldn't it be in the spec?

>> If there is a possibility that we are ever going to add decimal (or other
>> types for which === might not be an identity test), then adding Object.eq
>> now allows writing future-proof code for such things as memoizers --
>> whatever the semantics of === for decimals (or between decimals and
>> other numbers) turns out to be.
>
> JS developers have to cope with downrev browsers. There's no imperative
> "now" (ES3.1) vs. "next time", since they'll need something like the
> above as fallback for "last time" (ES3-based) browsers.

Unless they are targetting only ES3.1-and-above. At some point (maybe
several years) in the future, they'll be able to do that -- provided that

> Again my point is to avoid mission creep in 3.1. I have no problem with
> identical and hashcode.  If I'm wrong and they can be slipped in without
> any delay, filling inevitable latency in the current schedule, great.
>
> I should get busy on the spec.
>
> Ob. Bikeshed: You seem committed to eq as the name.

Not really, but eq has been used to refer to this operation for decades
in both the Lisp and capability communities. I can live with
Object.identical, but I'll always think of it as 'eq'.

--
David-Sarah Hopwood
```