Lars, many thanks for posting the interesting Adobe position paper. Could you explain a little more about your position on decimal support? In particular:
Your description of the standardization of decimal arithmetic as 'premature': The requirement for adding decimal arithmetic to ECMAScript was raised in TC39 in October 1998. The notes of TC39 WG meetings show this was discussed in the meetings of 1998/11 and also of 1999/11. The final TC39 'futures' list shows decimal support as being on the very short list of 'provisionally agreed' items for ES4, as of 1999/03. In the meantime, the decimal arithmetic in the IEEE 754 revision (754r, now in ballot) has been widely adopted, with extensions being made to many languages, including ECMA C# and CLI, Java, ISO C, Python, and SAP ABAP, to better support it. A number of C compilers ? including GCC ? already have the new decimal support, and software libraries are available from several sources. Hardware support is now available in two server architectures: power.org's PowerPC (since June 2007) and IBM's z10 mainframes (announced yesterday). In short, decimal support in ECMAScript is overdue, not premature. The 'use decimal' notation means that only knowledgeable users will get to use it: This is a valid criticism. This approach is not ideal, but at least means that where decimal arithmetic is essential it is available easily. In contrast, it is currently not available at all; it is very hard to replicate server-side calculations on the client using binary floating-point. However, the 'big red switch' approach that you advocate would probably be better ? in essence saying that external environments can override the arithmetic base used within scripting if the scripting engine supports that. What approach would Adobe favor for this? There have been a number of suggestions (for example, in an HTML context a meta tag in the <head> of a page could be used, which page builders could add by default for new pages). It is not necessary to define the mechanism for all hosting environments (and that is probably outside the scope of TG1 in any case). Your assertion that implementing decimal may be a hardship for implementations on smaller systems: Our current fixed-size decimal library, including all the 754r operations on both basic decimal formats (including FMA and many other functions and modes not needed for ECMAScript) are less than 80kBytes when compiled using GCC for Pentium. An ECMAScript implementation, using just one format, would probably need at most a third of this. Your assertion that implementing decimal may be a hardship for implementations that cannot use existing open-source libraries: There are now a number of open-source libraries implementing the 754r decimal types. At least two of these are essentially 'public domain' licenses. For example, ours is a part of the International Components for Unicode (ICU) library, whose license allows unrestricted use of source and derivative works in any project or product. The only requirement is acknowledgement of copyright. (For the full text of the license, which is just three paragraphs, see http://source.icu-project.org/repos/icu/icu/trunk/license.html .) We have had no requests or suggestions that would imply that the ICU license would prevent any implementation from using the library. The ICU libraries are widely used in many projects and products (including a number of Adobe products). Thanks ? Mike - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Mike Cowlishaw, IBM Fellow IBM UK (MP8), PO Box 31, Birmingham Road, Warwick, CV34 5JL mailto:[EMAIL PROTECTED] -- http://www2.hursley.ibm.com/mfcsumm.html Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
