Mike, Peter, Herman, Sam, Waldemar, Clayton, Chris, Rich, Jeff, Patrick Beard, Robert Ginda
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:
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.a.b::c
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.
"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.
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).
"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".
Proposal was labeled clever but dubious. Reservations were noted.function f( ... rest={a:3, b:17} ) f(a:7, c:22) === rest={a:7, b:17, c:22}
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.
Import namespaces is something that Microsoft has implemented which is not currently part of the proposal.
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.
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:
This was deemed useful in function overloading. Common idiom of function programming but perhaps too obscure for inclusion in the spec.function spoo ( x : singleton(o) ) {} function spoo ( x : singleton(l) ) {}
"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).
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
Given:
Waldemar indicates that the following two boolean expressions shouldvar a = (short) 256; var b = 256;
Herman differs on the first example. Herman prefers Number (essentially double), for both backward compatibility and understandability.a*a == (short) (0) b*b == 65536
The meaning of the following was discussed:
Waldemar interpreted this as 0, Herman interpreted it as 65536.b = a*a
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.
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.
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.
where id can be defined asid id ... id { var | const | function | class "{"..."}" } declaration
Microsoft has a need to persist the meta-information about a variable for access by other languages.const id = Version(...);
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:
The concern is that this syntax can be ambiguous.Version("3.0") var foo;
Herman's example of:
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.Version("3.0") function foo()
My example of
generated the following as an counter-example as ambiguous:var foo : Version("3.0")
Peter proposed using special characters such as ., "<[ ... ]>" or "[: ... :]", which seemed to generate no support.var foo : bar
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.
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)Early discussion (not yet an explicit proposal) was made to add a parameter to eval which specifies the scope.
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
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.