Es-discuss - several decimal discussions
rubys at intertwingly.net
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
>> 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
> 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
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
>> 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.
- Sam Ruby
More information about the Es-discuss