ES3.1 Proposal Working Draft
brendan at mozilla.org
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
> >makes the language larger and more complex, imposing a general
> >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:
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.
Engine bug on file at https://bugzilla.mozilla.org/ (to wit, https://
bugzilla.mozilla.org/show_bug.cgi?id=5856). 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