Consistent decimal semantics

Brendan Eich brendan at
Mon Aug 25 16:55:37 PDT 2008

On Aug 25, 2008, at 4:41 PM, Waldemar Horwat wrote:

> We're going round in circles on a few issues surrounding Decimal.

It seems to me people have reached the conclusion you already did on  
===. I'm not sure anyone advocated otherwise (I've missed most 3.1  
calls lately, so can't be sure).

>   Some of these have clear resolutions; others have a little wiggle  
> room.  Here's my summary:

Thanks, the FAQ format is helpful. I agree with your answers, but I  
have a couple of questions.

> - Should decimal values behave as objects (pure library  
> implementation) or as primitives?
> If they behave as objects, then we'd get into situations such as  
> 3m != 3m in some cases and 3m == 3m in other cases.  Also, -0m !=  
> 0m would be necessary.  This is clearly unworkable.

What should be the result of (typeof 3m)?


> - What should cross-type === do on 5 === 5m?
> These objects are of different types, so it should return false.

Confusion: 5 is of "number" type (a primitive type, typeof agrees),  
so "These objects" should have been "These values" -- right?

Sam and I, not going in circles (much), agree that typeof 3m should  
be "object", and that we add hardwired operator support for such  
Decimal objects.

> - How should mixed type arithmetic work in general?
> There are a few consistent design alternatives:
> 1.  Always disallow it.  For consistency you'd have to disallow ==  
> between Number and decimal as well.

This was what Igor Bukanov and I were advocating last week.

> 2.  Allow it, converting to the wider type (Decimal128).  There are  
> a couple design choices when doing the conversion:
> 2a.  Convert per the IEEE P754 spec:  5.1 turns into  
> 5.099999999999999644728632119949907m.  This is how most programming  
> languages operate (C++, Java, Lisp, etc.) when converting among the  
> built-in floating point values (float -> double etc.).

(I'm asking anyone who thinks so, as well as asking for your  
opinion:) Better than alternative 1? If so, why?

> 2b.  Convert the Number to a string and then to a Decimal:  5.1  
> turns into 5.1m.  As a special case, -0 would turn into -0m.  This  
> might work, but I haven't thought through the implications of this  
> one.

Interesting idea.


More information about the Es-discuss mailing list