September TC39 meeting notes

Waldemar Horwat waldemar at google.com
Fri Oct 3 12:49:48 PDT 2008


Since no one else has posted notes, I will.  This is not meant to be a complete summary; it's just the notable items that I happened to write down.  These are *not* minutes of the meeting.


- The current plan is to submit ES3.1 to a vote at the June 2009 ECMA General Assembly.  The successor is ES-Harmony and will come later.  A suggestion was made to insert another version in between ES3.1 and ES-Harmony which would be essentially equivalent to ES3.1 in behavior but written in a more formal spec language.  This would not have much of a benefit to the users of the standard and the suggestion was rescinded.

- We're still agreed that we will want two independent implementations of ES3.1 before submitting the standard to a vote.  Mozilla will likely have one.  MarkM will ask the Chrome guys about implementing it.

- Test suite:  The Mozilla test suite is used by Mozilla, V8, and others.  It's MPL-licensed which Microsoft doesn't like.  Mozilla will look into what it will take to relicensing it to an MIT-style license.  One approach to avert political problems would be for some or all of the test suite to become an ECMA document to make it easier for Microsoft can read it.

- We pretty much agree on the ES3.1 features, but the writeup in the document is still buggy and needs work, particularly chapters 8 and 10.

- In strict mode there is a strong desire to prohibit uses of <F.caller> and <F.arguments> where <F> is a Function object of a function that has an active stack frame, as well as uses of <arguments.caller>.  It creates an interesting dilemma in that these features are not in the ES3 spec, so how does one remove something that doesn't officially exist?  One possibility is to state that implementations *don't* do this, which was Waldemar's preferred position, but the committee thought that this was not strong enough because code that tried to access these would read <undefined> instead of throwing an exception.  We reached consensus on requiring implementations to define on strict functions <F.caller>, <F.arguments>, and <arguments.caller> with non-deletable, non-writable properties that have getters that throw exceptions when read.  An open question is what happens if one uses the reflection API to extract the exception-throwing getters:  are they all == to each other?

- Is the Array <length> property a getter when viewed via the reflection API?  If it is, are the different getters == to each other?  Not clear at this point.  Allen doesn't care, MarkM wants it fully specified, Waldemar wants closure joining back iff it is unspecified and the committee was sympathetic to that.

- Minor Date language cleanup issues.  Wording changes.  Agreed to the <now> method.  Agreed to require that methods that return the current time return non-decreasing values under normal operation (i.e. if someone doesn't manually change the machine clock).

- We briefly reopened the discussion of whether <const> is in the language.  The resolution was that it is in (unless of course nobody does the work to include it in the spec).  We agreed that <const> should be written at the point of initialization rather than have write-once semantics; the latter could be subverted as in:

{
 ...
 const x=2;
 function f() {
   return x;
 }
 function g() {
   // possibly x = 5;
 }
}
If g() runs first, then f() might return something other than 2!

An open issue is whether const violations should be compile or run-time errors.  Clearly some of them are undecidable and can only be reported at run-time, but what about the clear-cut cases?

{
 a = x;
 const x = 2;
}

- <Object.clone> was proposed.  Waldemar shot it down due to various technical deficiencies and the committee agreed.

- A syntactic rule was proposed to disallow any statement following a <return>, <break>, <continue>, or <throw> statement in order to cut down on errors.  Waldemar pointed out that this would fire for non-dead code such as:

 if (x)
   ...
 else
   return z;
 foo();

where foo() isn't dead at all.  Other legitimate places to have statements are after a <break> in a <switch>.  There wasn't much desire to change its semantics so that it would look for dead code (that would require specifying whether ... can proceed or not), so it was dropped.

- We were wondering why ES4 had a version of <eval> that did not capture the enclosing scope.  This does not appear to be permitted by ES3, which requires that <eval> either evaluate in the current scope or throw an EvalError.

- The contained <statement> inside a labeled statement should be a <substatement> in the grammar.

- In strict mode, a variable reference inside a nested scope must not evaluate to a Reference whose base is null rather than a Reference to a property of the global object.  The latter would prohibit legitimate references to Window.foo inside a function.

- Discussion about syntax of <use strict> directive.  Most favored option is the string literal "use strict" or "use strict,xxxxx" where xxxxx are arbitrary characters at the beginning of the program.

- The semantics of Function.bind were essentially broken and need to be rewritten.  We also changed its semantics so that bind works exactly as though the additional arguments were supplied at the point of the call, which means that you can use bound functions with both function calls and the <new> operator and have them behave as expected.

- Dropped efforts to reflect the names of parameters.  Many of the ones in the ES3.1 spec have names that are convenient for the algorithm writeups but don't make sense otherwise:  <Object.defineProperty> would have the parameters ["O", "P", "Attributes"].  This also wouldn't extend to the rest parameters that we'll introduce in ES-Harmony, so it's premature to standardize it now.

11.9.3:  Step 15 on is dead code.
Step 19 is dead code.

15.13.1.1:  What's a 34 digit integer?  For example, 7 is not a 34 digit integer.

15.12.1:  What does it mean to parse 1?

15.12.2:  What does it mean to contain cycles?  What if the cycle is filtered out?  What if the object modifies itself as it's being read (due to getters or side effects from toJSON routines)?


DECIMAL AND IEEE 754-2008

Mike Cowlishaw gave a presentation about Decimal and the IEEE 754-2008 standard which replaces IEEE 754-1985.  New things in there (most of which apply to both binary and decimal floating-point values) include:

- New 64 and 128-bit decimal types and 128-bit binary type.  The decimal types each have two incompatible representations.
- Hexadecimal float literals
- Round-to-nearest-ties-away-from-zero mode
- Fused multiply-add
- minnum and maxnum (min and max that ignore NaNs)
- Number-string conversions now must be correctly rounded.  ES3 already specified that.
- Classification routines (isNaN, isFinite, etc.)
- quantize and sameQuantum
- Signed NaNs
- 36 trigonometric and such functions which must be correctly rounded to the last bit.  Apparently that's now possible to do, although nobody has actually done for the power function.  Luckily these don't have to set the inexact flag correctly ;-).

Most of the above are mandatory.  Making things mandatory even where they don't necessarily apply seems to be the culture of the IEEE 754 committee.

Deleted from IEEE 754:

- Some ways of detecting underflows
- Traps are no longer mandatory

Mike Cowlishaw published a decFloats C package under an MIT-style open source license:  http://speleotrove.com/decimal


Mike Cowlishaw's preferred semantics of Decimal keeps track of trailing zeroes in some ways that several in the committee consider bizarre:

 1.00 + 1  -->  2.00
 1e12 - 1e12  -->  0e12
 5 + 5  -->  10
 1/.1  -->  1e1
 1/3 - 1/3  -->  0e-34

The values 10 and 1e1 are operationally different.  This causes problems for array lookups where the index is converted to a string:  a[1e4] and a[100*100] would refer to different elements.  IBM gave in on this point and we all agreed to not track trailing zeros (i.e. distinguish among cohort members) at all in ECMAScript.

The "m" decimal literal suffix is in for ES3.1.  It's the only non-downwards-compatible-with-existing-browsers syntax change in that spec.  The spec needs to be updated to include it.

We discussed and agreed that four of the Math routines (min, max, abs, round) should work on both binary and decimal floats in the natural way.  The other ones can coerce to and return only binary floats.

Sam is implementing Decimal in V8 (and Mozilla?).

Waldemar reviewed the current writeup of Decimal and struggled to understand it.  We now agree on what the behavior should be, but pretty much every section of the writeup needs to be corrected or rewritten.  Sam will do the work and Waldemar will review.


ES-HARMONY

We spent most of Friday on ES-Harmony, with a long discussion about the role of types.  We agreed that having types be symbols or badges ("interfaces") that some classes can export and can be used to annotate variables and parameters would be a good direction to follow.  We got at least tentative agreement on:
- Types should be sound.  If <a> has type T, and no one changes <a>, then <a> should continue to have type T.
- There should be a mechanism for requesting a concrete type (instead of anyone who claims to implement an interface) in situations that call for it.  The simplest way to do this would be to allow classes to be used as types (in addition to interfaces), but that's still considered controversial.  Other possibilities include some way of "freezing" a badge.  I hope we can make a bit faster progress on this.


UPCOMING MEETINGS

(I assume that the first day of each meeting is for the secure scripting subgroup.)

Nov 18-20, Royal Kona Resort, Hawaii  (heh, in today's economy the hotels there are cheaper than in Redmond)
Jan 27-29, Google Mountain View
Mar 24-26, Washington DC


   Waldemar


More information about the Es-discuss mailing list