Revisiting Decimal

Brendan Eich brendan at
Wed Jan 14 21:05:06 PST 2009

On Jan 14, 2009, at 7:38 PM, Kris Zyp wrote:

> Hash: SHA1
>>> You need to change this in any case, since even though the JSON
>> RFC allows arbitrary precision decimal literals, real-world
>> decoders only decode into IEEE doubles. You'd have to encode
>> decimals as strings and decode them using domain-specific (JSON
>> schema based) type knowledge.
> No, every Java JSON library I have seen

You've seen

It and the json.js alternative JS implementation are popular. json2.js  

         String.prototype.toJSON =
         Number.prototype.toJSON =
         Boolean.prototype.toJSON = function (key) {
             return this.valueOf();

> parses (at least some, if not
> all) numbers to Java's BigDecimal.

JSON has nothing to do wth Java, and most implementations do not have  
Java BigDecimal, so I don't know how it can be relevant.

> JSON's numbers are decimal,
> languages that support decimals agree. Dojo _will_ convert JS
> decimal's to JSON numbers regardless of what path ES-Harmony takes
> with typeof, whether it requires a code change or not.

That will break interoperatability between current implementations  
that use doubles not decimals.

> We already agree that the decimal-double comparison will always be
> false.

No, only some for ==. See 

1.5m == 1.5        	true

> The point is that this is representative of real world code
> that benefits more from the treatment of decimals as numbers.

It's not a question of more or less. If you let decimals and numbers  
mix, you'll get data-dependent, hard to diagnose bugs. If you do not,  
then you won't (and Dojo maintainers will have to work a bit to extend  
their code to handle decimals -- which is the right trade. Recall Mr.  
Spock's dying words from STII:TWoK :-).

> If that's true, that's fine, I have no problem with Dojo feeling the
> pain for the sake of others, but I still find it very surprising that
> Dojo code would be so misrepresentative of real code out there today.

It's not necessarily representative. It's not necessarily mis- 
representative. But we need to agree on how decimal as proposed  
compares to number (double) first, since from what you wrote above I  
see misunderstanding.

> Dojo covers a very broad swath of topics. Do you really think real
> world JS is that much different than Dojo's?

I have no idea, but this is completely beside the point. Breaking  
typeof x == typeof x => (x == y <=> x === y) for decimal will break  
existing code in data-dependent, hard to diagnose ways.

Adding a new typeof code will not depend on the value of a given  
decimal: any decimal will cause control to fall into an else, default,  
or unhandled case, which is strictly easier to debug and fix. Plus,  
any future JS standard with Decimal will be a big enough deal that  
porting will be obligatory and understood, by the time browsers adopt  


> Kris
>>> /be
> - --
> Kris Zyp
> SitePen
> (503) 806-1841
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla -
> LDIAmgLvpzAW8500idQvyTFaXQ4+eRPv
> =cn6y

More information about the Es-discuss mailing list