ES3.1 Proposal Working Draft

Brendan Eich brendan at
Wed Feb 20 14:39:38 PST 2008

On Feb 20, 2008, at 1:00 PM, Adam Peller wrote:

> >Each of us has some pet addition we think would be a great  
> addition to
> >the language. "const", "decimal", getters and setters, destructing
> >assignment -- all these have come up just this morning!. Each of  
> these
> >makes the language larger and more complex, imposing a general  
> diffuse
> >cost on everyone.
> Mark, as I recall, the discussion at the March meeting in Newton  
> involved implementing decimal arithmetic in ES3.1 to *replace* the  
> floating point implementation in ES3, thus "no new syntax". Yes,  
> this would have unexpected results for those who actually have code  
> logic which expects a value of "46.19" pounds, in Mike's example  
> (see Numbers thread).
Hi Adam, Mike:

I'm not sure what was to blame for that Machester car-park example --  
IEEE double can multiply 4.2 by 11 and round properly:

js> 11*4.2
js> (11*4.2).toFixed(2)

Cc'ing Mike in case he knows the full story (it's a fun example and  
useful real-world evidence of something, I bet).

> but the benefits here seemed to far outweigh this discrepancy.

No, sorry -- too much real-world code, not to mention synthetic  
benchmarks, depend on hardware-implemented floating point. There are  
also enough numerical and semi-numerical JS apps around that count on  
IEEE-754 double precision quirks that we cannot change the number  
type without opt-in versioning.

Anyway, the idea of ES3.1 as I understand it (and at least Mark  
Miller agrees) is not to promulgate a new, incompatible version with  
a distinct MIME type (including version= parameter). ES3.1, everyone  
involved at the last Ecma TC39 meeting seemed to agree, could be done  
as an Ecma TR (Technical Report). I'm against it becoming the next  
(4th) edition and making its way to ISO, especially if it has few  
changes from ES3, and I believe others involved in TC39 are also  
opposed to that.

Being vague about 3.1 possibly including ES4 features is a sure way  
to delay both any useful 3.1 TR and the full ES4, which is now  
entering a multiple-interoperating-implementations phase of  
standardization. If we have to keep monitoring and arguing about  
what's in 3.1 that might not be exactly the same in 4, to preserve  
the 3.1 < 4 subset relation, we all lose (by my definition of "lose").
> I can't speak to the technical level of detail that Mike can, but  
> at a high level it's seen as a bug by the vast majority of users,  
> and for all practical purposes, that's what it is.

Yes, I keep reciting its status as the most duplicated JavaScript  
Engine bug on file at (to wit, https:// But that does not mean it  
can be fixed with an incompatible change. The thinking for ES4 was to  
support a 'use decimal' pragma, for block- or wider-scoped explicit  
"opt in". This proposal,

with this discussion page

stood for a while, but was superseded by

And I believe there was an email conversation or two in which Mike  
was included. At this point, I would find it helpful to summarize the  
thinking on usable alteratives for decimal in ES4, and try to reach a  
consensus in this list. But again, I do not believe we can change the  
number type incompatibly -- that ship sailed in 1995. :-(


More information about the Es4-discuss mailing list