Consistent decimal semantics

Sam Ruby rubys at
Thu Sep 4 12:21:08 PDT 2008

2008/9/4 Brendan Eich <brendan at>:
> On Sep 4, 2008, at 8:30 AM, Sam Ruby wrote:
> In particular, does that imply the need for a wrapper class?
> Yeah, if you want !0m == true then we are back to the future:

There's a reason why my weblog is called Intertwingly :-)

> * There's a decimal primitive type, autowrapped when used as an object by
> Decimal.
> * The decimal primitive acts like a value type.
> * Decimal wrapper instances are mutable objects manipulated by reference.
> * Decimal.prototype contains methods, etc.
> * Calling Decimal(x) as a function converts a la Number.
> This was an outcome Lars Hansen explored earlier this year or late last
> year, when we were trying to align ES4 decimal (primitive only, shares
> Number.prototype) with ES3.1 Decimal.
> Sorry I steered you down the "Decimal is an object" route. As you argued,
> that plan is tenable if we can live with !0m == false, but it seems unusably
> confusing and fatally frustrating to generic programming (if (!falsy) ...).

Much good came out of the exercise.  Decimal primitives won't share
Number.prototype.  I believe that any new types that this committee
may contemplate in the future will bump up against this same
constraint: namely if that type has any values which should be
considered false, then they too will need to provide both a primitive
and a wrapper.

The end result is internally consistent, and simple.  Number and
Decimal are different types, but conversions (that are both precise
and safely round trip) are applied when the two are mixed.

The amount of changes to the following are minimal:

I will, however, be adding a few more tests.  Specifically, I want to
ensure that Decimal mimics the existing behavior for Number with
respect to the following:

js> Number(1) === Number(1)
js> Number(1) === new Number(1)

> /be

- Sam Ruby

More information about the Es-discuss mailing list