Revisiting Decimal

Brendan Eich brendan at
Thu Jan 15 15:28:33 PST 2009

On Jan 15, 2009, at 3:05 PM, Kris Zyp wrote:

> I
> more ambivalent on typeof 1.1m than on the what seems to me to be a
> more obvious mistake of throwing on JSON serialization of decimals.

Good to hear. Ambivalence should not be a stable state, though. If we  
can get to typeof agreement, let's do so. It seems to me ambivalence  
should mean "no", not "yes".

> [hundreds of cited lines deleted -- please trim when replying. /be]

>>  If you really endorse "receiver
>> makes it right", give a spirited and explicit defense.
> JSON already encodes in decimal.

No, you are assuming your conclusion again. "JSON already encodes in  
decimal" meaning "JSON encoding writes base ten floating point with  
optional exponent numbers" does not employ the same meaning of the  
word "decimal" as the decimal type contemplated for Harmony. The  
latter has semantics in addition to syntax. JSON's RFC says almost  
nothing about semantics.

> Do you want a defense of how a
> receiver should make right what is already right? We can't argue about
> whether JSON should have a more explicit type system. JSON is frozen.

Sorry, seems to me you are ducking again. Please address the  
incompatible change from JSON in self-hosted codes and the native  
ES3.1 codec encoding only doubles using JSON number syntax, vs. your  
proposal where with decimal added to the language we encode decimal  
and double as JSON number syntax.

> All decimal use is
> opt-in anyway, there is no breakage for existing code when the VM is
> upgraded.

What do you mean by "opt-in"?

If JSON peer Alice starts using decimal and encoding financial data  
sent to existing, double-based peer Bob, does Alice lose money? If no,  
show how. If yes, then show why such a bug is not a fatal flaw in your  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Es-discuss mailing list