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 46.2 js> (11*4.2).toFixed(2) 46.20 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 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, http://wiki.ecmascript.org/doku.php?id=proposals:decimal with this discussion page http://wiki.ecmascript.org/doku.php?id=discussion:decimal stood for a while, but was superseded by http://bugs.ecmascript.org/ticket/222 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. :-( /be _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
