Es-discuss - several decimal discussions

Brendan Eich brendan at mozilla.org
Sun Aug 24 10:35:44 PDT 2008


On Aug 24, 2008, at 9:34 AM, Sam Ruby wrote:

> What should the result of the following expressions be:
>
>   1.5m == 1.5
>
>   1.5m === 1.5
>
>    typeof(1.5m)
>
> A case could be made that both binary64 and decimal128 are both
> numbers, and that a conversion is required.

For ==, yes. For ===, never!


> A case could be made that
> while they are both numbers, the spec needs to retain the behavior
> that users have come to expect that conversions are not performed for
> strict equality.

We must not make strict equality intransitive or potentially side- 
effecting. Please tell me the case should be made, not just could be  
made.


>  And finally, a case could be made that the result of
> typeof(1.5m) should be something different, probably "decimal", and
> that decimal128 values are never strictly equal to binary64 values,
> even when we are talking about simple integers.

I'm sympathetic to the "decimal128 values are never strictly equal to  
binary64 values" part of this case, but that's largely because I am  
not an advocate of === over == simply because == is not an  
equivalence relation. == is useful, in spite of its dirtiness.

Advocates of === for all use-cases, even those written by casual or  
naive JS programmers, are just setting those programmers up for  
confusion when === is too strict for the use-case at hand -- and  
they're setting up the TC39 committee to add three more equality-like  
operators so we catch up to Common Lisp :-(.

The place to hold this DWIM fuzzy line is at ==. Do not degrade ==='s  
strictness.

The typeof question should be separated. You could have typeof return  
"number" for a double or a decimal, but still keep === strict. I  
believe that would be strictly (heh) more likely to break existing  
code than changing typeof d to return "object" for Decimal d.

I don't see why we would add a "decimal" result for typeof in the  
absence of a primitive decimal type. That too could break code that  
tries to handle all cases, where the "object" case would do fine with  
a Decimal instance. IIRC no one is proposing primitive decimal for  
ES3.1. All we have (please correct me if I'm wrong) is the capital-D  
Decimal object wrapper.


>> Guy Steele, during ES1 standardization, pointed out that some Lisps
>> have five equality-like operators. This helped us swallow === and !==
>> (and keep the == operator, which is not an equivalence relation).
>>
>> Must we go to this well again, and with Object.eq (not an operator),
>> all just to distinguish the significance carried along for toString
>> purposes? Would it not be enough to let those who care force a string
>> comparison?
>
> I think that a "static" Decimal method (decNumber calls this
> compareTotal) would suffice.  Others believe this needs to be
> generalized.  I don't feel strongly on this, and am willing to go with
> the consensus.

Premature generalization without implementation and user experience  
is unwarranted. What would Object.eq(NaN, NaN) do, return true?  
Never! Would Object.eq(-0, 0) return false? There's no purpose for  
this in the absence of evidence. I agree with you, compareTotal or  
something like it (stringization followed by ===) is enough.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080824/0123b1d0/attachment-0001.html 


More information about the Es-discuss mailing list