ECMA 262 Technical Meeting
May 15th, 1998
Notes from TC39 Technical Subgroup Meeting
Bill Gibbons
Present:
Norris Boyd (NS)
Mike Cowlishaw (IBM)
Jeff Dyer (Nombas)
Tom McFarland (HP)
Bill Gibbons (Ind.)
Waldemar Horwat (NS)
Mike Ksar (HP)
Clayton Lewis (NS)
Drew Lytle (MS)
Karl Matzke (Sun)
Mike McCabe(NS)
Herman Venter (MS)
Rok Yu (MS)
Likely issues to be discussed (other than ballot comments):
- Unicode - additional work may be delayed to V2
- Y2K - TBD
Changes to V1 document in response to ballot comments to be ready for that meeting.
It is expected that ECMA will take the final ISO version and approve it as ECMA262 edition 2. (Note the distinction between *edition* 2 and *version* 2.)
In the following discussion of ballot comments, only those comments which had not yet been resolved (including any changes to the draft) were discussed.
* Change title. Agreed, as specified (without diacritical marks, more or less):
ECMAScript : un language de programmation multiplate-forme a usage general
(No other action on our part.)
(#5, section 3) Agreed; Karl, Mike C. and Bill G. need to sort this out. [Not yet done.]
(#7, section 4.1) Item 1: No change; clause 4 is non-normative. [Right?]
Items 2, 3: Agreed, typos to be fixed. [Done.]
(#3, section 2) Not accepted; the conformance description in this clause reflects the
intent of TC39 as is. (However, the clause is being rewritten for other
reasons.)
(#9, section 4.2.1) First typo: already fixed.
Second type: No discussion? [Does not appear to need fixing.]
Meaning of arrow from CF to CFp: add legend "explicit prototype link".
[Done.]
Dotted lines - make them more explicit. [Done.]
(#10, section 4.3.1) Accepted, already done: second sentence was deleted.
(#11, section 4.3.9) Not accepted; this is a non-normative section, so definitions need
not be as precise.
(#12, section 4.3.15) Not accepted; this is a non-normative section, so definitions need
not be as precise.
(#13, section 4.3.16) Accepted, already done.
(#14, section 4.3.19) Accepted, already done.
(#15, section 5.1.2) Accepted, Waldemar will provide the fix to 7.1, including adding
comments and line terminator into the grammar. [Done.]
(#16, section 5.1.2) Accepted, draft to be clarified. [Done.]
(#17, section 5.1.4) Accepted, change "end-of-line character" to "line terminator". [Done.]
(#18, section 7.3) Accepted, draft to be clarified. [This looks quite clear to me already;
I don't believe any change is needed.]
(#19, section 7.3) Accepted, change "not...or" to "neither...nor". [Done.]
(#20, section 7.8.1) Accepted; add definition of "for statement header" to 12.6.2.
[Done; added definitions of "header" and "body" w.r.t. iteration
statements in 12.6. This could easily be formalized in the grammar,
but that seemed to violate the "minimum change" rule.]
(#21, section 8) Accepted; combine the "standard" and "internal" type lists and remove the
implicit definitions of the terms "standard" and "internal". [Done.]
(#22, section 8.6) Not accepted; section 4.2 is a non-normative overview so strict
consistency with the rest of the document is not required.
(#26, section 11.11) Accepted; fix typo. [Done.]
(#29, section 14) Ordering issue: not accepted, the grammar specifies left-to-right order.
First/last term of (1) issue: not accepted, the draft is sufficiently clear.
Typo, "is" in italics: accepted, fix. {Done.]
Typo, "is" without preceding spece. Accepted, was already done.
(1) Accepted; make the indicated changes and move any additional non-ISO references to
clause 4. [Done; however, there are no references to DIS 14651 or 14652 so these
documents are omitted.]
(2) Accepted, but use 646-IRV instead of 646. [Done, but there are no references to
DIS 15897 so this document is omitted.]
(3) Not accepted; the intent is to allow only 16-bit characters and only as "code points".
(4) Reference: accepted, using 646-IRV. [Done.]
Size of a character: not accepted; intent is to limit to 16-bit characters.
(5) Not accepted. (My notes are not clear as to the reason.)
(6) Not accepted; this would be too large a change from existing practice, and certainly
such a change cannot be considered at this point in the V1 process.
(7) Not accepted; the intent is to allow only 16-bit characters and only as "code points".
(8) Accepted, but to be fixed by making the reference non-normative. [Done.]
(9) Not accepted; too large a change for V1; issue deferred to V2.
(10) Accepted, except that character encodings are limited to 16 bits. Change the
reference to ASCII to refer to ISO/IEC 646-IRV and replace the reference to RFC1738
with an explicit description of the mapping as described in RFC1738.
[Done; since the algorithm is completely specified in 15.1.2.4 already, the reference
to RFC1738 was not necessary anyway. But note that the list of characters which much
be mapped is quite different in ECMAScript (as specified) and RFC1738. So the draft
contradicted itself; by default, the explicit algorithm takes precedence.]
(11) Not accepted; the intent is to allow only 16-bit characters and only as "code points".
(12) Not accepted; the intent is to allow only 16-bit characters and only as "code points".
(13) Not accepted; such a change cannot be considered at this point in the V1 process.
Issue deferred to V2.
(14) Not accepted; this would be too large a change from existing practice.
(15) Not accepted; this would be too large a change from existing practice.
(16) Not accepted; the mechanism for handling daylight savings time is implementation
dependent. The phrase "by whatever means are available" had already been removed
from the draft.
(17) 15.9.1.12: not accepted; the interpretation of "year" in "MakeDay" is depends
entirely on "YearFromTime", which does not have special treatment of years 0-99.
15.9.2: not accepted; not applicable.
(18) Not accepted; this would be too large a change from existing practice.
(19) Not accepted; this is outside the scope of this standard.
(1) Accepted; replace clause 2 paragraph 2 as specified. [Done.]
(2) Accepted; add to future reserved words. [Done.]
(3) Not accepted; the Number type is not restricted to 32 bits and may represent
integral values larger than 2^31, for instance using IEEE floating-point
double precision as an internal representation (handling 53-bit integral values).
(4) Not accepted; such a change cannot be considered at this point in the V1 process.
Issue deferred to V2.
(5) Accepted; delete description of "arguments" property of Function instances.
[Done.]
(6) Not accepted; this would be too large a change from existing practice, and it
is not a necessary restriction.
(7) Not done, pending feedback.
(8) Accepted; add the appropriate text. [Done.]
(9) Accepted, with changes; add the description of how to evaluate Identifier.
Otherwise, no change: the behaviour of variable declaration within With statements
is somewhat confusing but it is existing practice and cannot be changed at this time.
(10) Not accepted; this mechanism was added deliberately to describe the behaviour of
existing implementations.
(11) Accepted, change draft accordingly. [Done.]
(12) Accepted; add restriction that [[class]] must be a string and remove the
conversion in 15.2.4.2. [Done.]
(13) Accepted, except that positive array lengths in [2^31,2^32-1) are still valid
(they are perfectly valid values for a Number). [Done.]
(14) Not accepted; the intent is that the comparison function can return strings
as long as the result of ToNumber applied to those strings yields the right
behaviour. In reviewing this section it was observed that step 3 is difficult
to interpret. Restructure the algorithm to make it more clear. Also add
text saying that when the comparison function is inconsistent, the result is
implementation-defined. [Done, although some details may remain.]
(15) Accepted; make the suggested change. [Done.]
(16) Accepted; make the suggested change. [Done.]
(17) No such comment; numbering error.
(18) Accepted; make the suggested change. [Done.]
- The proposed changes to the conformance clause (discussed later).
- The list of document references (handled as part of the above comments.)
Suggested result - No substantive change, implementation must do any additional mapping.
Remove reference to "URL" from 1.1.2.4 [Done.] Will consider UTF8 versions in V2 -- tracking via status document.Editorial notes - Clarify that "For characters whose..." only applies to mapped characters. [Done.]
Globally change ASCII to ISO646-IRV. [Done.] Edit to remove reference to RFC1738 is described elsewhere in notes.
Strict equality - for strings, does NOT do any code point mapping; just uses the raw code points. So strings which are logically equal may not be strictly equal. Agreed to move these sections to "completed" status.
Break & Continue - sorry, I don't have notes on this.
Try and Catch - issue: replace all instances of "generate runtime error" in the draft with "throw the following value".
Expressions statements (12.4) - agreed that this is "complete".
Except within comments and string literals, every ECMAScript program shall consist of only characters from the first 128 Unicode characters (that is, the first half of row zero).[Done.]
Issue: should the draft refer to a specific version of Unicode? Should other references to standards documents specify the version? Not clear that there was an answer here.
Combining characters - should ECMAScript's behavioural model deal with abstract characters (which may consist of multiple 16-bit values) or abstract 16-bit values? One possibility: say that ECMAScript is Unicode 3 compliant, but that functions and operators deal with ECMAScript characters as Unicode "code points" and therefore do not deal with combining characters.
That would mean that existing functions can never handle combining characters, which implies that more complex Unicode character handling would require new functions (as with C, Java, etc.)
Agreed to accept the new Unicode conformance statement [Done, but with the slightly different wording in the ECMA ballot comments instead of the wording in Mike's paper]; add cross-reference to 7.7.4 and 15.5; maybe also 4.3.16 and 4.3.17. [Done for 7.7.4 but not 15.5, which did not seem necessary; and for 8.4 instead of 4.3.16-17, because 8.4 is the normative version.]
In 8.4, change "Unicode characters" to "characters, where an ECMAScript character corresponds to a Unicode code point". Check for and fix other instances of the phrase "Unicode character".