Es-discuss - several decimal discussions

Sam Ruby rubys at
Sun Aug 24 11:30:06 PDT 2008

Brendan Eich wrote:
> 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.

If we go with "object", a Decimal.parse methods won't be strictly 
(heh-backatcha) necessary, a Decimal constructor would do.  In fact, 
decimal could also be called as a function.  I like it when things 
become simpler.

My only remaining comment is that might tip the scales as to whether or 
not 1.10m === 1.1m.  They certainly are not the same object.  But we 
previously agreed that this one could go either way.

> 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

- Sam Ruby

More information about the Es-discuss mailing list