On Sat, Aug 23, 2008 at 11:44 AM, <[EMAIL PROTECTED]> wrote: > On Sat, Aug 23, 2008 at 1:49 AM, Mike Cowlishaw <[EMAIL PROTECTED]> wrote: >>> Finally, I'd like to take a poll: Other than people working on decimal >>> at IBM and people on the EcmaScript committee, is there anyone on this >>> list who thinks that decimal adds significant value to EcmaScript? If >>> so, please speak up. Thanks. >> >> Decimal arithmetic is sufficiently important that it is already >> available in all the 'Really Important' languages except ES >> (including C, Java, Python, C#, COBOL, and many more). EcmaScript is >> the 'odd one out' here, and not having decimal support makes it >> terribly difficult to move commercial calculations to the browser for >> 'cloud computing' and the like. > > Decimals in Java are implemented at the library level, as > java.math.BigDecimal. There is no expectation that intrinsic math > operators work on them. Is this approach valid for ES; if not, then > why not?
Decimal implemented as a library would be sufficient for a 3.1 release. The problem is an interoperable definition for what infix operators is required for completeness. Taking no other action, the default behavior for the result of a "+" operator given a Number and a library provided Decimal would be to convert both to string representations and concatenate the results. This was discussed at the last ECMA TC39 meeting in Oslo, and was found to be unusable and would create a backwards compatibility issue for Harmony. An assertion was made (reportedly by Waldemar and Brendan -- I wasn't present) that spec'ing the operators would not be all that difficult. To be sure, I then proceeded to implement such functionality using the then current SpiderMonkey (i.e. pre TraceMonkey, meaning I'm facing a significant merge -- the joys of DVCS), and found that it wasn't all that difficult. Based on the results, I've updated the 3.1 spec, and again found it wasn't all that difficult -- precisely as Waldemar and Brendan thought. At this point, I don't think the issue is infix operators. A few don't seem to like the IEEE standard (Waldemar in particular tends to use rather "colorful" language when referring to that spec), some have expressed vague "size" concerns when at this point it seems to me that we should be able to express such in measurable terms, and finally there are some usability concerns relating to mixed mode operations that we need to work through. More about this in a separate email. > Implementing decimals at the library level has the advantage that they > can be deployed today, as functional (if slower) ES code, and > optimized later on by a native implementation with no loss of > compatibility. After all, it will be several years before the next ES > version becomes reliably available on consumers' browsers. Does this > manner of easing migration inform the approach being taken? > > Conversely, if one is to add support for the intrinsic math operators > on decimals, does the required work generalize easily to arithmetic on > complex numbers and matrices? Will the addition of complex numbers and > matrices require more difficult work about how they interoperate with > existing number representations (including, at that point, decimal > numbers)? How, if at all, does this inform the present discussion? Judging by other programming languages, the next form for Number that is likely to be required is arbitrary precision integers. While we can never be sure until we do the work, I do believe that Decimal will pave a path for such additions, if there is a desire by the committee to address such requirements. > Ihab > > -- > Ihab A.B. Awad, Palo Alto, CA - Sam Ruby _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
