JSON numbers (was: Revisiting Decimal)

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Thu Jan 15 19:16:29 PST 2009


Brendan Eich wrote:
> Long ago in the '80s there was an RPC competition between Sun and Apollo
> (defunct Massachusetts-based company, but the RPC approach ended up in
> DCE), with both sides attempting to use open specs and even open source
> to build alliances. Bob Lyons of Sun argued eloquently for one standard
> type system for senders and receivers. Paul (I forget his last name) of
> Apollo argued for "receiver makes it right" to allow the funky
> non-IEEE-754 floating point formats of the day to be used at the
> convenience of the sender. E.g. Cray and DEC VAX senders would not have
> to transcode to the IEEE-754 lingua franca, they could just blat out the
> bytes in a number in some standard byte order.
> 
> Bob Lyon's rebuttal as I recall it was two-fold: 1. "receiver makes it
> right" is really "receiver makes it wrong", because the many types and
> conversions are a fertile field for bugs and versionitis problems among
> peers. 2. There should be indeed be a lingua franca -- you should be
> able to put serialized data in a data vault for fifty years and hope to
> read it, so long as we're still around, without having to know which
> sender sent it, what floating point format that obsolete sender used, etc.
> 
> The two points are distinct. Complexity makes for versionitis and bug
> habitat, but lack of a single on-the-wire *semantic* standard makes for
> a Tower of Babel scenario, which means data loss. Fat, buggy, and lossy
> are no way to go through college!
> 
> See http://www.kohala.com/start/papers.others/rpc.comments.txt for more.

This analogy fails to reflect the design of JSON.

JSON does specify a common encoding and type of numbers:
arbitrary-precision decimal, encoded as a decimal string. 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 can argue, if you want, that the common encoding and type shouldn't
have been arbitrary-precision decimal. 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. ES-Harmony must support JSON as it is designed;
changing JSON is not in scope for TC39, and is quite unlikely to happen
independently.

It is true that if the designer of a JSON-based format wants to simplify
its use across languages, then it would be helpful to implementors of the
format, all else being equal, if it did not assume that numbers will
be preserved with greater precision or range than an IEEE double.

However, if a JSON-based format *needs* numbers that are preserved
to greater precision or range than IEEE double, then JSON numbers
are still a perfectly suitable type to encode them (the only vaguely
reasonable alternative would be to encode the numbers as strings,
which doesn't solve anything; it just makes for a more obscure use
of JSON).

In that case, implementors of the format must find a JSON language
binding that supports a type with the required precision and range --
but such bindings are widely available for languages that have such
types (decimal or otherwise) built-in or supported by a standard library.
Presumably, ES-Harmony will be such a language, and its JSON library
will be extended to have an option to decode JSON numbers to decimals.

(ES-Harmony's proposed decimal type still isn't arbitrary-precision,
of course, but it will have sufficient precision and range to support
a larger set of uses than IEEE double.)

> 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. They can also encode both ES numbers and ES decimals to JSON numbers,
as Kris has already indicated that Dojo plans to do. (This encoding is
lossy in general, but not necessarily lossy for a given use of JSON.)

>> JSON does not follow the path of other formats that attempt to dictate
>> tight language-type couplings. In all cases, peers can ultimately
>> choose how they want to internally handle the data provided by JSON.
>> JSON is pure data format, not computation prescription and won't
>> dictate how computations are performed.
> 
> Yeah, yeah -- I know that and said as much. The argument is not about
> JSON as a syntax spec, it's about what we do in the implementation in
> ES3.1, where we have to make semantic choices. Including types and
> typeof, including future proofing.

AFAICS the most helpful thing in that respect would be to give
programmers some expectation about how decimal is likely to be supported,
so that they will have the maximum amount of time to future-proof their
code, and it will be more likely that it Just Works when decimal starts
to be supported by implementations. (Obviously they will still need to
test on the implementations that support decimal first.)

-- 
David-Sarah Hopwood ⚥



More information about the Es-discuss mailing list