ECMA TC39 meetings 23-24th September 1999

These notes cover the 3 meetings that took place consecutively at HP Labs, Bristol:

Present:

Mike C
Dave
Clayton
Waldemar
Andrew
Herman
Richard
Chris
Mike M
Sam

Sam is arrived late via a taxi from Gatwick airport. We also expected Tom Greene (WAP Forum) to appear the following day, but he never made it.

Final Text

Herman and Waldemar to share writing down changes to the text as Bill Gibbons has moved to a new job. The latest version of the document is 18th August. Waldemar has plenty of points to bring up. We decide to go through it page by page.

Mike would like to note our thanks to Bill for his great job!

In 4.3.15, we would prefer consistent capitalization for terms like Boolean. In 4.3.21 we want to strike the last 2 sentances, e.g. the ability to define shared properties on the Number prototype.

In 5.1.2 Waldemar would like to mention the regex grammar for completeness. He also wants to change the example for iterators on page 27.

In 7.1 Herman would like some examples as he doesn't understand the current wording. Richard mentions Arabic uses the Unicode left to right and right to left marks. The format-control characters are removed during lexical analysis and hence are invisible to the parser.

In 7.6 Waldemar notes that UnicodeEscapeSequence is defined in both 7.6 and 7.8.4. He would like to strike one of these. We prefer to strike the definition in 7.6 and add a forward reference. We also want to add precise definition of Escape.

The text on rounding on page 23 is inconsistent with the last. We decide to delete the 2nd sentence in the section on semantics which says "The rounding mechanism is unspecified ..."

Richard likes the 1st sentence of 7.8.4, but Waldemar wants a change. We decide to stay with the current text. Richard notes that the Unicode standards have changed from Unicode code point to a new term.

7.8.5 2nd para comprised of changed to comprising. Richard proposes we treat it as explanatory text rather than as a note.

In 7.9 Waldemar wants to insert the do while statement which is missing. He also wants to reword 7.9.1. We agree that we need to change the way the example for semicolon insertion applies to for statements in 7.9.2 Perhaps using a new name for semicolons in the for statement.

On page 33 CanPut needs to be added just after the table. In 8.7.1 and 8.7.2 Waldemar thinks that you can never get to the 2nd statement and hence want's to strike these and also the text "If Type(V) is a Reference" in the 1st statements.

In 9.1 we decide the strike the last sentence at the end of the table. In 9.3.1 we need to strike the redundant text on rounding. In the last paragraph, Waldemar wants to copy the text from 8.5 (better English). In the table in 9.9 we need to capitalize boolean and number.

10.1.2 remove "nested" from first bullet point. We delete something else (which I didn't catch). In 10.1.4 last sentence, perhaps change from result of "binding" to "evaluating". We haven't defined the term "binding".

In 10.1.5 change window from monospaced text to "the window object" in normal text.

11.1.2 insert "evaluating" before "an identifier" In 11.2.2 we want to clean up the evaluation steps for new. We discuss what happens when you fall off the end of a function without a return statement. Step 8 will be deleted.

11.3.1 step 4 - can we word this better? Ditto for step 7 in 11.6.1. In 11.7 semantics, the first sentence is wrong. We decide to delete the paragraph. Similar problems with truncating in 11.7.1 and 11.7.2.

11.8.6 step 8 should be result of 7 not 6.

12.4 as per the handout plus the insertion of with between "with" after "cannon start". In 12.14 you can only have one catch which must occur before 'finally'.

Section 13 semantics, 1st bullet. Waldemar proposes to add some explanatory text (see handout) that permits you to reuse an existing function object when the scope chains are the same. This allows the implementor to avoid unnecessary allocation of closures, but doesn't require this to be done.

Chris notes that the language Pop doesn't allow this leading to observed practical problems. Herman is queasy about this and thinks it's an edge case. We talk about this for a while and decide to come back to it later.

Herman is uncomfortable about the NOTE in 13.0 as his implementation provides access to the function identifier, and the note forbids this. Waldemar sketches:

function f()
{
    ... g ...

    with (x) {
          a = b ? function g() { ... } : function g (){...};
    }                             ^
}                                 |
                                  |
                                  |
Can we get access to 'g' here?  --

We think that this shouldn't be forbidden.

Brief history and Contributors?

Clayton hasn't yet done the former. Mike C would like to compile the list of contributors and has been through all the available materials to draft one. He runs through it verbally. We rule out people who only came to the business meetings but not to the technical sessions. We add in people who contributed by email even though they didn't attend the technical sessions directly.

Back to the spec ...

In section 15, we discuss the treatment of the object prototype object. Herman proposes clarifications.

15.2.4.6 move step 3 to step 5.

Waldemar's handout covers changes to 15.3.4.3, these are editorial and accepted. Ditto 15.3.4.4. DontEnum is missing from 15.3.5.1.

There is a potential circular reference in 15.4.4.5 but we decide to leave the text as is. We have fixed a bug in 15.4.4.8 in steps 12 or 14. In 15.4.5.1, step 13 is changed for consistency with arrays.

Richard objects to the use of the words left and right in the context of 15.5.4.7 and would prefer before and after. Left and right are display properties and potentially different from how characters are stored in memory. The same comments apply to 15.5.4.8.

15.5.1.1 the undefined value is converted to the word "undefined". This is for historical reasons.

15.4.4.10 the proposed change is incompatible with current practice. No changes through 15.5.4.11. The discussed a proposal received via email. Waldemar says he likes it but that its too late given current implementations.

Waldemar talks about regular expression matching with empty strings. 15.5.4.15 is changed to always take 2 arguments. The 2rd paragraph is fine as it stands. 15.7.4.2, Waldemar wants to add undefined to "the number 10 or not supplied".

15.10.3.1 is new - RegExp(pattern flags). Waldemar writes:

RegExp(/a*b/).exec("aaab")

People would write something like this and wonder why it doesn't work. What you really want is:

/a*b/.exec("aaab")

However this already works:

RegExp("a*b^").exec("aaab");

Herman asks about the flags. We agree that if you can't honor it then throw an error. How about a type error?

In 15.10.4.1 both the pattern and flags are now required. RexExpError should this be SyntaxError? Yes.

Major changes to 15.10.6.4, see Waldemar's handout. We agree to the changes as per the handout. 15.10.7.* are missing DontEnum.

15.11.6 - we discuss error objects and what happens when no message is provided. New language is needed for 15.11.1. We can strike the clause "whose value is the empty string" in 15.11.4 says Herman.

Problems occur if builtin properties are changed which then interfere with subsequent error handling. Unfortunately we aren't free to make these properties read-only.

We agree to replace the snippet of JavaScript in 15.11.6 by a more detailed description. Waldemar would like to strike 15.11.6.1. Mike M. writes:

obj = {}
foo = {valueof:function(){return obj;}
   toString: ... }

1 + foo

Waldemar notes that this would return a type error.

We divert to B 1.3 where Waldemar's changes are accepted.

Herman asks whether we really need a grammar summary? Mike C says he finds it really helpful and avoids the need to search backward and forward through the spec. This section has been hand compiled by Bill. Richard asks about the order - should it be in the same order as the rules appear in the spec? Mike C suggests we keep it as it is. Waldemar and Herman agree to do a first check with Mike C doing the final check.

We talk briefly about the 2 digit year stuff but decide to leave this aspect of the spec alone. It already includes notes advising the use of the 4 digit year alternatives.

We debate what to do about 08 and 09 which the spec defines as errors, but which are widely interpreted as decimal rather than as octal. One radical solution would be to pull octal. We decide to add to the NOTE on page 23 to the effect that 08 and 09 are treated as though they were decimal. Any other cases where 8 and 9 appear in number literals starting with 0 are implementation dependent and may result in an error.

We would like to make Octal non-normative. Mike proposes to move the Octal productions to the compatibility appendix (B). So resolved! We can then remove the corresponding examples.

Waldemar asks if we can move the Octal escape sequences out on the same principle. Yes. This means that Octal will no longer appear in the main body of the standard.

Mike C takes us through a series of questions he has received via email from Peter Torr.

Schedules

Errors, History and People list. Mike wants the final document to be available on October 11th. The new text needs to available for people to check on the 4th or 5th. The 6th at the latest. Mike will pass the document to Yan on the 11th.

Function Definition (chapter 13)

We return to Waldemar's proposal and try to reach consensus on the ability to re-use closures. Waldemar will reformulate text, but in principle, Herman is agreed to the feature.


Friday September 24th - Business meeting of TC39

I arrive at 9:20 to find Clayton reporting on the ECMA GA. Rows on who owns the term "DCD", and discussion on Java.

Working Group Reports

Mike proposes to move that we accept the spec and pass it to the GA. Seconded by Richard. No objections.

Not much has happened on the Modularity subgroup, although we have a better shared understanding and general concensus on the direction. This work was deferred while work on edition 3 was completed.

The I18N subgroup has worked on what features should be in the I18N library but the fine details have yet to be defined. The subgroup has put most of its efforts into the review of I18N features in edition 3. One of the things dropped from the group's plans is a message catalog as they felt that this is best handled by a different layer.

Editor for edition 3. Bill Gibbons has left and Herman and Waldemar will take over.

Editor for edition 4? Mike C proposes Sam. Mike will be leaving his position in TC39 as Project Editor after November.

What about moving edition 3 through ISO. This took some 6 months effort for the previous edition. General feeling that its not worth progressing edition 3 through ISO and that we should wait until we have done edition 4. Clayton will ask Jan van den Belt for comments on the possible downside to ECMA.

Item 8: ECMA standardization of Music APIs for ECMAScript? We feel happy to assist, but it won't become part of our work plan. We suggest that if ECMA goes ahead with work on music apis, it should be in a separate group.

Item 9: Dave moves that we set up a wireless subgroup. Seconded by Chris, no objections. We decide to call the subgroup "Lightweight ECMAScript". The subgroup will propose the scope for its work. A meeting will be arranged in November or perhaps October. One suggestion is that we leave the binary encoding to WAP. We would like to invite a representative of the WAP Forum to participate in the work group.

ECMAScript components subgroup (ECMA 292). This may need revision to accommodate ECMAScript edition 4 work on modularity.

Item 10: Schedule for edition 4. What goals do we want to state? Herman proposes we plan to take a year. The main goals are modularity and I18N libraries. We may want to include the Lightweight subset in the edition 4 standard. Higher performance and more flexibility in implementations. Better support for commercial arithmetic. Convergence with W3C.

AOB. none.

Date and place next meeting - we decide 6 months time feels right, say April? Friday March 31st on the West Coast hosted by Netscape.

end of meeting

Clayton calls Tom Greene in case Tom was on his way to meet with us. Clayton will contact him next week to set up the first meeting of the Lightweight ECMAScript subgroup. (We discover Tom is in the US and we've called him at 2am!)


Modularity Subgroup Meeting

After prolonged discussion we agree to:


Dinner at the Royal Crescent Hotel

Jenny Raggett and view to the bar

Waldemar and friend

Clayton

Jenny and Chris

Richard and Waldemar

group scene

group scene

Chateauneuf du Papeamazing cheese platenicely presented dessert