On Aug 23, 2008, at 8: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?
See http://jroller.com/cpurdy/entry/the_seven_habits_of_highly1 (especially the first comment, by Bob McWhirter) also see https://bugzilla.mozilla.org/show_bug.cgi?id=5856 All linked from the still-useful http://wiki.ecmascript.org/doku.php?id=discussion:decimal > 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. http://gwt-math.googlecode.com/svn/trunk/gwt-math/src/main/resources/ com/googlecode/gwt/math/public/js/bigdecimal.js ;-) > After all, it will be several years before the next ES > version becomes reliably available on consumers' browsers. Several years or less than a year from final spec, depending on the vendor's commitments to standards. > Does this > manner of easing migration inform the approach being taken? Not really. If you want GWT, use it. If you want a library, they are out there. The problem is making a new type in ES3.1's spec work, both now and in the future when operators are added (so we can avoid the laughable but totally predictable outcome Bob McWhirter cited in Purdy's blog). > 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? We might hope to know by looking at other languages, but really, doing the work in the context of backward JS compatibility is required. So again, doing what Sam is doing in developing patches against open source JS implementations seems at least as valuable as trying to spec Decimal quickly, making it "law", and then hoping it works out in the future *and* somehow leads to a taller numeric tower. > 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? You might find http://wiki.ecmascript.org/doku.php?id=proposals:generic_functions interesting. Obviously not a live proposal, but if we ever want operators, I'm still in favor of multimethods instead of hardcoding. The current untestable spec can't stand much more complexity in its runtime semantics. If we ever get complex numbers, quaternions, etc., they should come by users defining operator multimethods after the committee has retired in victory to the same Valhalla where Dylan and Cecil are spoken :-/. /be _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
