These notes cover:
Dave, Clayton, Chris, Waldemar, Patrick, Sam, Richard, Andrew, Herman, Peter, Mike M, and Jeff
Herman has helped with the Word formatting issues and the group agrees that the resultant version of the E3 spec should be forwarded to ECMA.
We agree to fold this back into the main technical group. this is now appropriate as it is dominating the work we are doing.
There is concern that the provisional list of agreed new features for E4 is too long for completion by December 2000. Herman is concerned over the potential impact of changing numeric literals to be decimal numbers (currently these are defined as the type double). Dave proposes we defer discussion of decimal numbers until Mike Cowlishaw can report on the changes that decimal numbers would require to the E3 specification.
Herman wants to us to commit to December 2000 and scale back on on work to meet this deadline. Andrew thinks this is unrealistic even for a subset. Clayton thinks that nonetheless it would be valuable to set a milestone for December. Dave proposes that we should set a milestone for at least two implementations of whatever features we have agreed.
Peter says biggest request from users is for types and classes. He wants to get a specification out early rather than waiting for the other features to be done. Richard says that generally speaking standards should lag implementation.
We agree to Sam's proposal that we aim to have content agreed for each section in the spec by December 2000.
Herman circulated a document covering the revisions to the E3 spec he thinks are needed to adding type annotations to ECMAScript.
Chris asks about [[HasInstance]], he notes that integers don't normally have instances. [[HasInstance]] is currently only implemented by function objects. Herman proposes that it also be implemented by type objects. He notes that the idea is to introduce types as type objects. Waldemar says to Herman, you mean to make types into first class objects. Herman says yes.
In 8.8.2 Herman introduces a step that applies a type check for PutValue. Types are immutable.
Herman notes there is a controversial issue. He wants type expressions to be statically evaluable. Waldemar strongly disagrees and prefers a dynamic model. Chris agrees with Waldemar.
Patrick would like to see a slightly expanded set of types e.g. string. He is also interested in restricted types e.g. integers in a given range. Herman proposes we defer these perhaps to E5.
Waldemar thinks Herman's namespace mechanism might clash with member lookup. There is some resistance to using dot for qualified names for types. Chris thinks we should use the same mechanism for types as we intend to use for package names. Another proposal is :: for use between the namespace qualifier and the type.
Waldemar and Chris would like the syntax for type expressions to be a subset of general expressions, even if we decide to limit ourselves for now to statically evaluable type expressions.
Herman assumes that namespaces are objects, hence his choice of dot for qualified type names. He sees types as sets of values. His intent is that you can compile this down to native types that can be supported effectively on typical architectures. This also makes easier to interface to other languages.
We discuss issues arising from loss of precision when assigning numeric literals to numeric variables such as long, e.g.
long L = 2000000001 * 2000000001
Edition 3 defines the types of numeric literals as double. The multiplication when performed as a double would then lose precision as compared to 64 bit integers.
Waldemar says "are we prepared to break backwards compatibility with Edition 3 so that we can introduce long?"
Herman says that he is not married to long. Herman feels that he essentially agrees with Waldemar and the issue is to come up with some wording to clarify what we mean.
During assignment conversion may be necessary, e.g. negative zero could become positive zero.
Waldemar writes:
int a = 0x7fffffff; // maximum value of long a++; // but what does this give?
We agree that we should remain backwards compatible with E3 except where there is an absolutely compelling reason why not. The handling of arithmetic seems one such case.
We then discuss whether we can unify objects and type objects, in other words, unifying constructors and types. Herman thinks this would complicate implementations.
Waldemar wants to know whether Herman's proposal can be extended or not. Does it preclude extension to dynamic type extensions.
var Distance = Number;
function f(x:Distance)
{
}
Herman notes that this is not allowed in Herman's proposal since his definition means that type expressions are not the same as general expressions.
In section 8.7 Jeff wonders if it is appropriate to use [[Class]] == "Type" to determine if an object is a type. Herman acknowledges that this is a hack, but it seemed like the easiest way to adapt the existing spec. All type objects will have to have [[Class]] and it therefore seems a reasonable thing to use.
Chris argues that we should start with a dynamic definition and then constrain this to be static, as then we can be ensured that extension to dynamic types will be practical. Waldemar also wants to make sure that the static case is a strict subset of the dynamic case.
We break for Lunch.
Clayton proposes we ask Waldemar to go through his proposal for dynamic type expressions at our next meeting.
We schedule one day meetings for Feb 17th Netscape and March 23rd Microsoft (Mountain View).
Update after the meeting: Clayton and Andrew believe that the second meeting should be in Redmond
Waldemar writes:
var foo:t = val; const foo:t = val;
Waldemar explains that const is in the Netscape implementation and means something whose value is evaluated dynamically but can only be assigned to once.
All of these declarations can be preceded by visibility modifiers: identifier, local, box, private, public and package. For example:
local var foo:t = val; private const foo:t = val;
identifier is for user defined visibility. Waldemar proposes allowing a version identifier between the visibility flag and the identifier. He notes that this syntax doesn't interfere with parsing in answer to a question from Herman.
We discuss the possibility of providing several flags. Waldemar has checked that a comma separated list enclosed by round brackets. Herman would prefer square brackets. The user defined flags are constructed by an expression. Waldemar writes
const deprecated = expression; /* this can then be used as follows */ deprecated var foo
Waldemar says another idea would be to follow the flags by a block. The flags would apply to every statement in the block.
private {
/* private stuff */
}
Herman, Waldemar and Chris all volunteer to study the issues relating to the syntax of attributes further with a view to reporting back in February.
Herman says we need to call the constructor of the parent class. He needs to implement this soon and hence wants us to agree on a syntax.
Richard asks what's wrong with following Java and use the "super" keyword. Waldemar and Chris are concerned about not precluding multiple inheritance. Chris adds that Java's approach precludes you from using it with declarations, since super must come first. This does however guarantee that the constructor is called first.
We agree to: the rule:
Either you explicitly call super at the start of a constructor or an implicit call to super will be inserted for you.
Waldemar proposes that semicolon is optional:
In lenient (aka compatibility) mode semicolons can be omitted if there is a line break (or a comment) and the next token cannot continue the current expression.
Herman says that he would prefer to keep semicolons optional in strict mode. Sam notes that the ability to leave out semicolons is an extremely popular feature in ECMAScript, so perhaps we ought to retain this. Waldemar wonders about making it a separate option from compatibility/strict mode. Herman questions who would set the option to make semicolons required.
Chris thinks it might be better to think of this in terms of when newlines are significant or not. Herman notes that this could break legacy scripts. Chris thinks that this can be worked around. Sam writes:
x = 3 + 2
This is a single statement, currently, as is:
x = foo ( ... long argument list ...)
Sam notes that we are probably stuck with a negative grammar.
Waldemar notes that this issue impacts the way we can introduce attributes into the language, and negatively impacts the ability for us to add other new features in the future.
Do we agree to the proposal to make semicolon optional for the addtional cases Waldemar outlined above (e.g. before 'else'). Herman says no, this would mean that new code could break old browsers.
Conclusion: semicolon insertion remains unchanged from E3.
We choose to formulate the work as a subgroup. The chair and editor will be resolved in the next meeting.
Asko starts off by explaining the background that led up to the definition of WMLScript. The current version is 1.2. WAP is now interested in working on an enlarged version. Some of the differences from ECMA 262 include the way errors are handled. WMLScript returns the value invalid rather than throwing an exception. Other differences include Pragmas, additional reserved words, libraries, and number formats.
Herman asks about the byte code format. Asko says that there is nothing preventing us adding new bytecodes as we go forward. A version identifier is present at the start and means we could make significant changes.
Asko asks should the byte codes be aimed at one specific language or multiple languages? Byte code converters could be executed on servers.
WAP want richer data structures. Access to devices is important.
Waldemar asks what percentage of mobile devices have floating point support? This isn't known at this time.
The memory size is of order 100-200 Kbytes for the bytecode interpreter plus libraries, and tens of kbytes for working memory. These figures are for WAP 1.2 and larger sizes can be anticipated for WAP 2.0. Perhaps doubling the 1.2 sizes?
WAP sees the need for a garbage collector as richer data structures are added.
WAP is looking to add a document object model support manipulation for XML. The size of the W3C DOM is a problem. Sam adds, this is true even on servers!
Dave runs through the proposed features for ECMAScript edition 4. Rich presents the I18N features in ECMAScript. Asko notes that WMLScript permits other character encodings to meet the desire of some Japanese companies to be able to use ShiftJIS rather than Unicode.
Currently the only machine dependency in WMLScript is the character encoding.
We discuss the compilation model. The persistance model is source text with compilation to byte code taking place in the gateways for both the scripts and the WML markup.
Netscape, Microsoft and HP are interested in participating as is Altawave, Phone.com, Nokia and potentially Ericson. The work could be done in ECMA, or it could be done in the WAP Forum and presented to ECMA. We have the potential to add features into ECMAScript as well as into WMLScript.
Waldemar and Sam think that one of major discrepancies is the way WMLScript coelesces undefined, NaN, null etc. into a single error value invalid. Computation then continues, unlike the exception model in ECMAScript edition 3.
If we can prove that the exception handling model in Edition 3 can be supported efficiently, then this could be adopted by WMLScript version 2. Our expectation is that this can be done.
WAP is meeting in Rome on February 6-11. It would be good for someone from ECMA TC39 to make a joint presentation with the WAP on the goals for the E4 work, goals for WMLScript v2 followed by a question and answer session. This would follow in the same model as the W3C presentations to the WAP Forum.
We wonder whether Mike Cowlishaw could go? Sam will email him asap. Dave could go, but we agree that Mike is our first choice.
WAP would like to complete version 2 by the end of 2000. If ECMA want to vote in December this means having the spec done in the Fall.
Tom and Clayton will work together to sort out the subgroup membership, and the positions of chair and editor.
| Clayton Lewis | Netscape | clayton@netscape.com |
| waldemar Horwat | Netscape | waldemar@netscape,com |
| Roger Lawrence | Netscape | rogerl@netscape.com |
| Rob Ginda | Netscape | rginda@netscape.com |
| Bill Gibbons | Pixo | bgibbons@pixo.com |
| Mike McCabe | Netscape | mccabe@netscape.com |
| Rich Gillam | IBM | rgillam@us.ibm.com |
| Peter Torr | Microsoft | ptorr@microsoft.com |
| Andrew Clinick | Microsoft | andrewc@microsoft.com |
| Herman Venter | Microsoft | hermanv@microsoft.com |
| Chris Dollin | HP | kers@hplb.hpl.hp.com |
| Jeff Dyer | Mountain View Compiler Company | jeff@compilercompany.com |
| Peter Brown | Altawave | pbrown@altawave.com |
| Tom Green | Altawave | tgreen@altawave.com |
| Sam Ruby | IBM | rubys@us.ibm.com |
| Asko Komsi | Nokia | asko.komsi@nokia.com |
| Dave Raggett | HP | dsr@w3.org |
| Patrick Beard | Netscape | beard@netscape.com |