Revisiting Decimal (generic algorithms)
brendan at mozilla.com
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