JSON numbers (was: Revisiting Decimal)

Brendan Eich brendan at mozilla.com
Thu Jan 15 19:54:04 PST 2009

On Jan 15, 2009, at 7:16 PM, David-Sarah Hopwood wrote:

>> See http://www.kohala.com/start/papers.others/rpc.comments.txt for  
>> more.
> This analogy fails to reflect the design of JSON.

The design of JSON is fine in isolation from the "facts on the ground".

You seem to be mistaking my argument against Kris Zyp's position that  
we can add decimal and encode it by default as an attack on JSON. But  
since, as you note here...

> JSON does specify a common encoding and type of numbers:
> arbitrary-precision decimal, encoded as a decimal string.

... JSON does have a (underspecified in my opinion, and clearly so  
based on so many codecs ignoring it) single format -- arbitrary  
precision decimal -- it does avoid "receiver makes it wrong" -- in  
theory. The lingua franca is BigDecimal or equivalent (not IEEE 754r).

Too bad no JS based JSON codec, and no ES3.1 draft spec, requires  
arbitrary precision decimal as the number type used when encoding and  
decoding. This makes it impossible to evolve implementations without  

> This is very
> different from "blat[ting] out the bytes in a number in some  
> standard byte
> order". (The difference is not text vs binary; it's using a  
> standardized
> encoding rather than the sender's encoding.)

You're preaching to the choir. My argument was against implicit sender- 
type-based encoding, which is what we have today for all JS codecs I  
know of.

> You can argue, if you want, that the common encoding and type  
> shouldn't
> have been arbitrary-precision decimal.

I never argued that.

> But the JSON RFC says what it says,
> and for better or worse, it does not mention any binary floating point
> types, or have any way to explicitly specify multiple number
> representations.

Yes, I know.

> ES-Harmony must support JSON as it is designed;
> changing JSON is not in scope for TC39, and is quite unlikely to  
> happen
> independently.

I never proposed to change JSON. Why are you arguing against that here?

>> We are not condemned to repeat history if we pay attention to what  
>> went
>> before. JSON implementations in future ES specs cannot by default  
>> switch
>> either encoding or decoding to use decimal instead of number.
> Of course not, but they can easily provide a non-default switch to do
> so.

That's necessary, and what I clearly advocated. I feel like tapping  
the mic ("is this thing on..." *tap* *tap*), since somehow you've  
managed to spend most of your reply arguing against positions I've not  

> They can also encode both ES numbers and ES decimals to JSON numbers,
> as Kris has already indicated that Dojo plans to do.

Dojo can do whatever it likes, but Harmony should not specify this by  


More information about the Es-discuss mailing list