Revisiting Decimal

Kris Zyp kris at
Wed Jan 14 21:32:42 PST 2009

Hash: SHA1

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

>>>>> 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 contains
>> String.prototype.toJSON = Number.prototype.toJSON =
>> Boolean.prototype.toJSON = function (key) { return
>> this.valueOf(); };

Of course, there is no decimal support in ES3, there is no other option.
> 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.
One of the major incentives for JSON is that it is interoperability
between languages. If other implementations in other languages treat
JSON's number as decimal than the assertion that I understood you were
making that JSON number's are being universally expected to be treated
as binary is not true.
> 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.
How so? And how did all the implementations that use decimals to
interpret JSON numbers not break interoperability?
>> 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
>> :-).

So you are suggesting that we shouldn't let users pass mix of decimals
and numbers even if they explicitly attempt to do so?
> 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 decimal.
It's not beside my point. If signficantly more real world code will
break due to violating the expected invariant of a constant finite set
of typeof results (and the expectation that numbers regardless of
precision will be typeof -> "number") than those that break due to
violating the expected invariant of typeof x == typeof x => (x == y
<=> x === y) than I think we would be negligent as language designers
to ignore that consideration. I understand the logical concerns, but I
would love to see real empirical evidence that contradicts my suspicions.

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

More information about the Es-discuss mailing list