Es-discuss - several decimal discussions

Sam Ruby rubys at
Sun Aug 24 09:34:40 PDT 2008

On Sun, Aug 24, 2008 at 11:13 AM, Brendan Eich <brendan at> wrote:
> On Aug 24, 2008, at 6:18 AM, Sam Ruby wrote:
>> A modest
>> request: if the code could be reviewed and feedback provided to me
>> with sufficient time for me to address the comments and the code to be
>> integrated into a nightly build, by default disabled, in time for the
>> Redmond meeting, I would appreciate it.
> Set the review flag to my bugzilla id -- othewise I won't see it in
> my request queue, and I'll probably forget to go review it on my own.
> Thanks.

I'll see if I can rev it first based on the changes we have been
discussing and to resync with the latest hg TIP.  Once that is done,
I'll set the review flag.  I was unclear on the process - thanks for
the tip.

>> Let's posit for the moment that adding two nickles and calling
>> toString() on the result produces "1.10"
> Where'd the buck come from? ;-) Ok, I'm with you so far...

Oopsie!  :-)

>> Furthermore assume that 1.10m > 1.09m and that 1.10m < 1.11m.
>> Given the above, as well as your knowledge of ES history, what would
>> you expect the results of evaluating the following two expressions to
>> be:
>>   1.10m == 1.1m
> true.
>>   1.10m === 1.1m
> true, but there's a weak case for false if you really insist that the
> significance is part of the value. If we make the result be false,
> then people who advocate always using === instead of == to avoid
> implicit conversions would be giving bad advice to Decimal users. I'm
> sticking with true for the reason given below.

That's the conclusion we came to.  An argument could be made for
either answer, but the stronger case, based on ES consistency, is for

You correctly anticipated the followup question, and I address that
below.  But your mentioning of conversions triggers a different line
of questions.

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.  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.  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.

Whatever the conclusion, neither the spec updates nor the code updates
would be difficult.

>> Depending on your answers, there may be a followup question.
> 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.

> /be

- Sam Ruby

More information about the Es-discuss mailing list