ECMA TC39 meetings 20th January 2000

Mountain View, 17th February 2000, hosted by Netscape


Mike, Peter, Herman, Sam, Waldemar, Clayton, Chris, Rich, Jeff, Patrick Beard, Robert Ginda


Chris confirmed this his notes too indicated that Andrew had suggested hosting the next meeting in the Microsoft facilities in the bay area.  I indicated that Andrew remembered this differently, and as host he should be able to choose. 

Resolved: location of next meeting is in Redmond.

Discussed Dave's proposal for a 2+1 day meeting in March.  General agreement that shorter meetings are more effective.  Suggestion was made that we consider more frequent partial day meetings - I pointed out that this was hard on the ones who need to travel across multiple time zones.  One day general meetings at roughly the frequency that we are holding them seems to be the best compromise for now.

Per Dave's suggestion, we will attempt to schedule the WAP subgroup meeting on the 22ns so that it would immediately preceding the general meeting on the 23rd.  Sam and Peter to follow up with Andrew to arrange facilities.

Discussion on how to make the meetings more effective. Herman proposed that we spend some time on a "meta agenda" in which we capture a list of areas where consensus is not reached.  This item was scheduled for the end of the day.

I indicated that I intended to give preferential treatment in scheduling agenda items for which there was a prepared presentation.

For this meeting, Herman want to focus on two areas:

  1. areas where Microsoft's near term implementation is not a true proper subset.
  2. issues where the ECMAScript proposal is a superset, but there is not a general consensus on this being the direction where we intend to go.

Walk through of selected subset of the JS2.0 doc


Coercion was an area with several areas of disagreement.  null was discussed as a interesting case. null is a member of all non-primitive types, but how should we handle areas like strings and integers. In the Microsoft implementation, strings are non-primitive so have nulls, integers are primitives and nulls are coerced into zero.


Section was skipped with a note of a disagreement on semicolon insertion by Herman.


"::" as a syntax was noted as an area where Microsoft's current implementation is not a proper subset.

Example from Waldemar and Chris:

Syntax of units (number not followed by a line break ) is an area of concern by Herman - not an area where they have an incompatible implementation as of yet.

Minor concerns were noted by various people (named arguments, commas in array expressions as a legacy issue, binary logical xor syntax). These will be covered in more detail in subsequent passes over the document.


Microsoft would like an explicit package statement with it's scope delimited by curly braces. The current proposal syntax associates packages with files and also permits packages in arbitrary scopes.

"static {}" in the Microsoft implementation follows the Java syntax. In Waldemar's proposal, the {} does not delimit a new scope, so static is just a syntactic convenience in which the static modifier is distributed throughout the declarations.

compile time block - Herman has significant reservations on this but did not elaborate. Waldemar indicated that he thought he added this on Herman's request. Noted and moved on.


Global, instance, and may-override, and parameterized attributes, and extents are noted as an areas in which Herman has reservations.


Again, differences on coersions. Microsoft coerces undefined to "zero-y" things.

Uninitialized const were discussed. Points of view include making it an error, or a zero, or some new manufactured value (a "wacky" way of enum).


Microsoft requires the keyword "abstract" prior to abstractFunctionDefinitons.

"new" as a way of introducing constructors is an area where the Microsoft implementation differs.

Herman inquired as to the meaning What is the meaning of an assignment Expression in a "restParameter".

function f( ... rest={a:3, b:17} )
f(a:7, c:22) === rest={a:7, b:17, c:22}
Proposal was labeled clever but dubious. Reservations were noted.


Reservations on classes being followed by an arbitrary blocks without restrictions.

Microsoft's current implementation allows people to implement host interfaces, something that needs to be resolved. Defining of new interfaces is not supported in either the Netscape proposal or the current Microsoft implementation.


MS has implemented composite names (identifier [. identifer]* ) and has similar reservations on packages containing arbitrary blocks.

Import namespaces is something that Microsoft has implemented which is not currently part of the proposal.

Language declarations

Variants of the language is controversial to the extent that it is not well understood.

The Microsoft implementation permits modes like "strict" (known as "Fast") to be supplied by the host. This is not precluded by the NS proposal. Discussion on how obvious this must be (in the script or on the <script> tag in web pages) particularly in the case where semantic differences are implied.

Line break as a consequence of strict is highly controversial.

Traditional is a controversial.


Herman inquired as to whether it useful to have a explicitly named value for "any".  Consensus is that any stays.

In MS implementation Array is anything created with new[], and does not include items from outside ECMAScript.

Array declarations in the MS implementation allow arrays to be declared by simply following the identifier with square brackets.  Waldemar indicated that this was omitted from the proposal for simplicity sake.

The type of numeric literals which do not contain decimals deserves further discussion.  Confusion between "int" and "Integer".

Predefined type constructions: existence of "+" is an area where Microsoft differs.  In the Microsoft implementation, every type contains null (so implicitly everything has a "+").  Chris indicated that he would find a "+" very helpful (though he could accept the changing the default).  All to often Java programs are littered with assertions of not null, and null pointer exceptions often only identify the victim, but not the culprit.  Reservations noted.

Reservation noted on "~" on the grounds that it is too subtle.

Example of singleton:

function spoo ( x : singleton(o) ) {}
function spoo ( x : singleton(l) ) {}
This was deemed useful in function overloading.  Common idiom of function programming but perhaps too obscure for inclusion in the spec.

"Severe problems" were noted on type annotations not affecting the semantic meaning of of a variable.  Deferred.

Issue noted with "@" as a syntax.  Commonly used as a preprocessor, but even if it was not, reservations would be present anyway.  The subtle distinction between casts and conversions is perhaps beyond the comprehension of our target market.  Coersions generally are lossless (but not always, again the distinction is very subtle - Waldemar clearly has an idea in mind, but the rest of us are quite as clear).


This is an area where the general role of versioning must be explored further before delving into a specific proposal.

Machine types

Name of the library is in question, and which of these are available without requiring import.  Should "" correspond to the natural length of an integer or be deemed to be 32 bit value across all platforms?  The argument was made that in the sake of understandability and portability, the need for a common definition  of "int" is important.

Editorial comment was made by Herman that: we should not fall into the all to easy assumption that the full extent of the outside world from an ECMAScript perspective is Java.  There are other interesting component models and platforms that need to be considered.  This was met with general agreement


var a = (short) 256;
var b = 256;
Waldemar indicates that the following two boolean expressions should
evaluate to true:
a*a == (short) (0)
b*b == 65536
Herman differs on the first example.  Herman prefers Number (essentially double), for both backward compatibility and understandability.

The meaning of the following was discussed:

b = a*a
Waldemar interpreted this as 0, Herman interpreted it as 65536.

We need to discuss this model in the context of arithmetic models, particularly as the implicit conversion into double is highly incompatible with the decimal arithmetic proposal.

Operator overloading

The proposal is to only allow overloaded to be defined in packages which define either the first or second arguments.  Apparently this matches fairly well to the Microsoft implementation.  Chris expressed a mild reservation.

Herman will bring the Microsoft consensus on which operators should be overloadable to a subsequent meeting.

Rich indicated that he felt that === should be a strict identity test.  ECMAScript 3 is full of counter examples: NaN === NaN is false. In the current implementation === does look into values for primitives (including strings).  Inclusion of defineIdentical in the list of overloaded operators is controversial.


Defer the semi-colon insertion discussion.

Waldemar noted in the type declaration section that re-introducing the C-style type declarations introduces no ambiguity.  Generally received as an interesting observation, but the consensus was that the it would be undesirable to have two syntaxes and the Pascalish syntax is established at this point.

Declaration attributes:

Waldemar introduced the discussion with:
id id ... id  { var | const | function | class "{"..."}" } declaration
where id can be defined as
const id = Version(...);
Microsoft has a need to persist the meta-information about a variable for access by other languages.

Herman indicated that it would be of value to allow constructors to be invoked directly on the declaration (as opposed to requiring a separate declaration).  An example would be:

Version("3.0") var foo;
The concern is that this syntax can be ambiguous.

Herman's example of:

function foo()
was explored and deemed to be an example of an syntax which requires the parser to be aware of the semantics, in general a bad idea.

My example of

var foo : Version("3.0")
generated the following as an counter-example as ambiguous:
var foo : bar
Peter proposed using special characters such as ., "<[ ... ]>" or "[: ... :]", which seemed to generate no support.

Consensus: declarations may be preceded with an id, followed without a line break by any sequence of identifiers and constructors.  Users are free to pick the initial identifier, and in many cases a scope modifier will do the job.  In case the user is not enamored of any modifier, "attributes" will be recognized as a an "identity" operation which does not modify the meaning of the declaration.

Initially, Microsoft implementation only allows literals as expressions within constructors.  Herman expressed reservations on having ECMAScript introducing any superset of this as it conflicts with his need to persist type definitions.

Waldemar noted that names are scoped, so definition of an attribute within a scope may override the meaning.

Semicolon insertion

Herman described the evolution of the current Microsoft implementation.  The original intent of strict mode was to turn on more error checking.  Over time, errors evolved into warnings.  Then it seemed best to simply issue the warnings all the time.  Ultimately this evolved into a "fast" mode instead which is a proper

Microsoft "fast" mode as currently implemented (to the best of Herman's recollection at the moment) as the following:

Don't allow standard object model to be modified, eliminate the arguments argument, and do not allow functions to be modified.
Herman repeated his strenuous objection to having strict or fast mode disable semicolon insertion.

Waldemar repeated his position that he would like to have a scope delimited option "use strict" which cleaned up this messy part of the language.

I observed that unfortunately semi-colon insertion is already a part of the language and unfortunately is too widely popular for it to be turned off now.  Herman agreed.

Discussion strayed from the topic at hand into discussions on how to defeat various warnings (for example, an explicit declaration of  a variable "extern" would be interpreted not as a new declarations, but as an alias for an existing declaration)

Extended discussion of strict vs. fast.  The primary difference is in the scope (fast, in order to work needs to be global, strict can and should be limited to a scope).

Clayton recapped the potential meanings of "strict"

No function aliasing (assigning to functions)
All variables must be declared
Lint style warnings
No arguments object
Eval restrictions (equals local scope)
Function argument count checks
No global object model writes
Semicolon insertion (on/off)
Assignment to constants disallowed
Early discussion (not yet an explicit proposal) was made to add a parameter to eval which specifies the scope.

General discussion as to the original purpose of strict mode.

 In the case of assuming that functions are const, the problem is that the current ECMA standard is that assignments to readonly don't delete properties are silently ignored, and Herman stated the position that defining const to mean something different is too subtle.

Meta agenda

I read selected excerpts from these meeting minutes, and Chris identified a number of omissions, which I folded in at that time.  I inquired as to whether this was the right level of detail for a meta agenda, but was overruled.  For now these meeting minutes will serve this purpose.  (Over time, I would still like to evolve to a section by section status such as the one Mike maintained during the evolution of the previous iteration of the specification)

Versioning revisited

Herman asserted that he has the exact same need for which the versioning proposal addresses within ECMAScript to address a larger scope - the proposal is to
introduce an "override" attribute.  This was met with general agreement.

Draft for the agenda for the next meeting

  1. decimal arithmetic - should we support more than one arithmetic (Mike)
  2. cost functions proposal for interfacing to external languages which support overloading. (Netscape)
  3. proposal for packages and classes (Herman)
  4. true type annotations - versioning/override proposal (Herman
  5. units (Chris)
TODO: Share recommendations on good COM introductory book