Adobe position paper on the ECMAScript 4 proposal space -- decimal

Mike Cowlishaw MFC at
Wed Feb 27 03:01:42 PST 2008

Lars, many thanks for posting the interesting Adobe position paper.  Could 
you explain a little more about your position on decimal support?  In 

Your description of the standardization of decimal arithmetic as 

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:'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 

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 .) 

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:mfc at  --

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Es4-discuss mailing list