Revisiting Decimal (generic algorithms)

Brendan Eich brendan at
Fri Jan 16 12:11:54 PST 2009

On Jan 16, 2009, at 11:16 AM, Allen Wirfs-Brock wrote:

> Returning to  Brendan's original question...

Thanks, this is a very informative reply.

> [much good stuff deleted]

> This problem cannot be fixed simply by tweaking the coercion rules.   
> It probably requires that numeric literals be treated as generic  
> values that are only interpreted situationally as either binary or  
> decimal values in the context of a particular operations.

That, or multimethods so we don't essentially carry around literals in  
source form and pay high costs converting them according to context.  
That was the ES4 solution at one point, until we started cutting.  
Based on Dylan and Cecil precedents:

> The design details of the integrations of multiple numeric data  
> types (potentially not just Number and Decimal) and questions such  
> as whether and how a dynamically typed language like ECMAScript  
> should support such generic algorithms will have long lasting impact  
> on the usability of the language.  My perspective in Kona, when we  
> talked about Decimal, was that these are Harmony scale issues that  
> must be carefully thought through and that they should not be  
> prematurely and irrevocably resolved as a consequence of an  
> accelerated effort to include Decimal in ES3.1.

Well stated. Everyone agreed on this point, as well as on the spec not  
being ready (and not in minor ways) -- both reasons led to decimal  
being cut from 3.1. We should work on the long-term solution, since  
bugs continue to be filed on unwanted rounding errors due to binary  
double precision. And we should not make mixed-mode honey traps via  
implicit conversions, including in JSON encoding.


More information about the Es-discuss mailing list