Revisiting Decimal

Kris Zyp kris at
Thu Jan 15 05:39:29 PST 2009

Hash: SHA1
Unfortunately, I don't have enough time to continue to point by point
discussion. If the group feels typeof 1.1m -> "decimal", then so be
it, we can certainly handle that. My point was to show empirical
evidence that could hopefully be considered in the decision process.

As far as JSON goes, Dojo will encode decimals to numbers, there is
really no coherent alternative (encoding to strings would be even more
bizarre, and I can't think of any other option).


Brendan Eich wrote:
> On Jan 14, 2009, at 9:32 PM, Kris Zyp wrote:
>> Of course, there is no decimal support in ES3, there is no other
>> option.
> This is not strictly true:
> The point is that JSON peers that do math on numbers, to
> interoperate in general, need to parse and stringify to the same
> number type. It may be ok if only ints that fit in a double are
> used by a particular application or widget, but the syntax allows
> for fraction and exponent, which begs representation-type precision
> and radix questions.
>> 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.
> It's probably a mix, with application-dependent restrictions on
> domain and/or computation so that using either double or decimal
> works, or else buggy lack of such restrictions.
>>> 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?
> Not necessarily. But correctness is not a matter of hopes or
> percentages. It may be fine for JSON to leave it to the app to
> choose number type and/or operations done on the data. But  some
> layer has to care. Some apps probably already depend on json2.js
> and json.js and the like (ES3.1's JSON built-in) using double, not
> decimal. Changing a future JSON codec to use decimal instead of
> double is not a backward-compatible change.
>> So you are suggesting that we shouldn't let users pass mix of
>> decimals and numbers even if they explicitly attempt to do so?
> No, I'm suggesting unintended mixed-mode bugs will be common if we
> make typeof 1.1m == "number".
>> 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)
> We can't measure this, realistically, but again: the breakage from
> a new typeof result is not dependent on the numeric value of the
> operand, and entails either a missing case, or a possibly
> insufficient default case, while the breakage from your proposal is
>  subtly data-dependent.
> Plus, the invariant (while not holy writ) is an important property
> of JS to conserve, all else equal.
>> than I think we would be negligent as language designers to
>> ignore that consideration.
> It's not a consideration if it can't be quantified, and if it
> introduces value-dependent numeric bugs. Decimal and double are
> different enough that typeof should tell the truth. 1.1m != 1.1,
> 1.2m != 1.2, but 1.5m == 1.5.
>> I understand the logical concerns, but I would love to see real
>> empirical evidence that contradicts my suspicions.
> I gave some already, you didn't reply. Here's one, about
> dojotoolkit/dojo/parser.js:
> "But if typeof 1.1m == "number", then str2obj around line 52 might
> incorrectly call Number on a decimal string literal that does not
> convert to double (which Number must do, for backward
> compatibility), ...."
> It won't do to assume your proposal saves effort and demand me to
> prove you wrong. First, no one has access to all the extant typeof
> x == "number" code to do the analysis and prove the majority of
> such code would "work" with your proposal. This is akin to proving
> a negative. Second, I've given evidence based on Dojo that shows
> incompatibility if typeof 1.1m == "number".
> How about we talk about an alternative: "use decimal" as a way to
> make all literals, operators, and built-ins decimal never double?
> The problem with this "big red switch" is that it requires
> conversion from outside the lexical scope in which the pragma is
> enabled, since code outside could easily pass double data into
> functions or variables in the pragma's scope. It requires a
> decimal-based suite of Math, etc., built-ins too, but that may be
> ok (it was contemplated for ES4).
> The problem with this old idea is really the challenge of ensuring
> conversion when cross the pragma's lexical scope boundary.
> Presumably double numbers going in would convert to decimal, while
> decimals flowing out would remain decimal. Even this is
> questionable: what if the callee was compiled without "use decimal"
>  and it's another window object's function that expects a
> double-number?
> /be

- --
Kris Zyp
(503) 806-1841
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

More information about the Es-discuss mailing list