JSON numbers (was: Revisiting Decimal)
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
> 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
> 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
> You can argue, if you want, that the common encoding and type
> 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
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
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
>> before. JSON implementations in future ES specs cannot by default
>> either encoding or decoding to use decimal instead of number.
> Of course not, but they can easily provide a non-default switch to do
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