use decimal

Brendan Eich brendan at
Wed Sep 17 12:49:50 PDT 2008

On Sep 17, 2008, at 6:54 PM, Douglas Crockford wrote:

> Also, programs that do opt in should continue to work as they do  
> now on the ES3
> processors. They will produce the same slightly incorrect totals,  
> but will
> otherwise behave as before.
> An implementation of decimal that does not meet these goals must be  
> rejected.
> I think these goals require that  typeof decimal_number  produce  
> 'number'.

Only under the "use decimal" pragma, right?

> It requires that  a === b  produce the same result as  typeof a ==  
> typeof b && a
> == b.

Without "use decimal", typeof 1.1m must not be "number" to preserve  
this same invariant. Otherwise (without "use decimal") 1.5m == 1.5  
but 1.1m != 1.1, so without making typeof 1.5m != typeof 1.1m, we  
cannot have typeof 1.5m == "number".

I do not believe anyone wants typeof 1.5m != typeof 1.1m.

So without "use decimal", typeof 1.1m and typeof 1.5m must be "decimal".

As discussed previously in late August, typeof applied to any decimal  
should not be "object" or else

typeof x == "object" && !x => x === null

is not preserved. Agreed?

> If the opt in mechanism is a string literal pragma as the first  
> statement of the
> program
>      "use decimal";
> then the processor can cause all number values created by the  
> compilation unit
> to have the decimal representation. On ES3 implementations, binary
> representations will provide approximate results.

Approximate, as in incorrectly rounded :-/.

Many people agree with the intent of your proposal, which has been a  
proposal from various people in similar form for a while. Evidence  
includes the fact that

keeps collecting dups. A "use decimal" should mean "use decimal as  

But double values leaking into a "use decimal" context, mixing with  
decimal values in expressions, could be worse than a rare exception.  
They could cause different control flow, depending on relational  
operators: the missile launches when it should not. They would tend  
to produce hard-to-find yet non-trivial bugs.

It would be better to make it an error for a double to flow into a  
mixed-mode expression in a "use decimal" context.


More information about the Es-discuss mailing list