ECMAScript TC39 meeting 7th June, hosted by Netscape

Participants

Clayton Lewis Netscape clayton@netscape.com
waldemar Horwat Netscape waldemar@netscape.com
Chris Dollin HP kers@hplb.hpl.hp.com
Lewis Theran Nokia louis.theran@nokia.com
Rok Yu Microsoft rokyu@microsoft.com
Herman Venter Microsoft hermanv@microsoft.com
Patrick Beard Netscape beard@netscape.com
Ted Wugofski Phone.com ted.wugofksi@corp.phone.com
Nick Okasinski Phone.com ??
Sam Ruby IBM rubys@us.ibm.com
Jeff Dyer Compiler Company ??
Dave Raggett HP dsr@w3.org
Mike McCabe Netscape mccabe@netscape.com

Next Meeting

July 14th in Redmond, hosted by Microsoft. The following meeting is on September 27-28th, in Bath.

Sam's Intro

Sam summarises the areas of substantial agreement. These have been drawn from meeting notes. See his file (agenda.htm).

He went on to list areas without substantial agreement. Sam also provided some action points for these.

He then calls for agenda items, but proposes we look at namespaces.

Waldemar wants to talk about constant expressions, the bracket operator, and namespaces. Clayton would like to hear from the WAP guys as to their expectations and to generally share info.

Ted says he plans to come to future meetings. He adds that he expects to bring a requirements document to the next meeting. Louis adds that the WAP WAE group devoted to scripting will be meeting this month and will be able to contribute to this requirements document.

Clayton asks if there are relatively few companies working on scripting in the WAP Forum. Ted replies, yes, although there are a lot more who are interested.

Herman notes that at the end of the last meeting we agreed to try and work on a cut down version of Waldemar's document just containing what we agree. Herman and Peter worked on this but found the result to lack an effective structure. He therefore suggests we continue to work from Waldemar's document, at least for now. He notes his editor has problems with the embedded JavaScript in Waldemar's document.

Waldemar agrees with Herman that once we have an agreed document, it will be easier to create a delta document, but working on the delta document in the interim would be rather hard.

Herman has annotated Waldemar's document with areas where he has disagreements. He now thinks there is broad agreement on namespaces, although the name needs to be changed and we need to work through the details.

Namespaces and the Square Bracket Operator

See page 29 of Waldemar's handout.

Waldemar notes that a["b"] = a.b cannot hold in edition 4 for a variety of reasons, e.g. security. He proposes an attribute "nonindexable" that can be used to hide a property from the array lookup mechanism, e.g.

class C
{
  nonindexable var x;
}

c = new C;

c.x     // succeeds
c["x"]  // fails

He ponders on whether it makes sense to add a modifier "indexable" for private variables, e.g.

class C
{
  indexable private var x;
}

He then discusses how ambiguities are resolved.

Herman says Microsoft thinks the proposal is too complex and too hard to explain. He would like to see different defaults.

By default, he doesn't want expando properties to be supported by default, although they would be ok if you declare the class as permitting expandos. This is covered in Peter's document on JScript7 as sent in email. Microsoft would like expando properties added by the bracket notation to not clash with statically declared properties.

Waldemar thinks the Microsoft proposal harms discoverability. Herman responds that if we want discoverability we should look a general reflection mechanism.

Chris thinks that the Microsoft proposal will prove a barrier for people familiar with current ECMASCript programming idioms.

Rok notes that for Microsoft COM doesn't provide the reflection mechanism which ECMAScript could hook into. This is only used currently in IE.

Nick thinks that providing full discoverability may impact the ability to compile code efficiently. He fears creating a separate mechanism for reflection when one is kind of already there. Waldemar agrees with this, let's keep whats there and build on it rather than adding a new mechanism.

Herman notes the primary disagreement is over defaults. He is concerned about the overhead of making properties indexable by default. He notes that in edition 3 there are already properties you can't find via the for-in mechanism.

We then switch back to discussing Waldemar's namespace proposal. Microsoft uses :: for declaring events and hence aren't happy about using :: for namespaces. Herman doesn't find the proposal compelling. Will most users be able to understand the syntax?

Herman says that "namespace" already has a use in programming languages, a different use from that proposed here. He would like to find a different word for it. Waldemar agrees. Herman suggests "name tag".

Herman would like to associate packages with namespaces. We discuss "use" and "import" as proposed by Waldemar.

We then reflect on the tension between a dynamic scripting language and a more static language that can be compiled for faster code. Clayton suggests that the guys writing HTML and JavaScript are more naive that the people writing code for server side execution.

Ted notes that a lot of client side scripts are thrown away. Mike explains the interest in libraries that work with old and new code.

Rok explains his concern about existing code running slower when moved to the new environment. Sam presses Rok on this.

Rok asks Herman if the square bracket mechanism covers the 90% of user needs for reflection. Herman agrees with this but adds that this brings with it unpleasant consequences for expando.

Chris asks what should we give up if we are going to do a respectable reflection interface for edition 4? He thinks doing reflection properly would be hard.

Herman suggests you could provide a specially named property for reflecting over an object. This wouldn't return a string but wouldn't work in exactly the same way as for-in, e.g. for x.properties in x.

Nick says that if you use a different type than string for iterating over properties, you avoid the security problems.

Waldemar notes that users are more likely to interested in iterating over the values stored in a hash table, than in the internal variables used by the hash table. Herman agrees.

Herman explains that Microsoft is largely driven by what they feel the users will want to do.

Ted says that people who wish to iterate through properties may well be different from those people who want reflection.

Herman says for-in is generally useful for dynamically added properties.

Louis asks if people around the table use reflection to modify object's behavior?

Herman would like expando (ad hoc) properties to be in a different namespace from the statically declared ones. Waldemar disagrees. Mike and Clayton argue that to make them different would break existing idioms people have come to expect to use.

Waldemar is unhappy with Herman's proposal that you have to explicitly enable ad hoc properties on a per class basis. Waldemar thinks authors may not know ahead of time whether ad hoc properties will be used or not.

Waldemar is not a fan of adding ad hoc properties, but he feels this however one of the defining characteristics of JavaScript.

After considering scripting classes imported from other languages Waldemar agrees to the idea of being able to control whether a given class supports expando or not.

we break for lunch

Compile-time constant expressions

This follows on from our last meeting. Waldemar directs us to page 9 of his handout. He talks us through his proposed definition of what it means to be a compile-time constant expression. These are rules that ensure that an expression when evaluated at compile-time must give the same result as when the expression is evaluated at run-time.

Waldemar's definition involves the notion of a side-effect free "pure function". He doesn't provide any means for programmers to add new pure functions. These can only be provided by the implementation. Simple rules can be used to determine if an expression is a compile-time constant, e.g.

  const a = 17;

  a + 5   // is also a compile-time constant

Herman is doubtful about the need for this. He thinks that such expressions will primarily be useful as type expressions and that these can be reasonably restricted to much simpler expressions.

Do compile-time constants need discussion in the standard or is this a implementation optimisation issue? Waldemar answers that the reason why we need to define this if for places in the standard which must accept a compile-time constant, e.g. a type expression.

Waldemar then talks about conditional declarations. Herman admits that this is what he is nervous about.

function f(x)
{
    if (x)
    {
        const e = 2.71828;
        x += e;
    }

    return x;
}

Chris explains that he would hate to have to evaluate the conditional to determine whether or not "e" exists in the scope of the return statement.

Chris and Herman think that as var already effectively hoists the declaration to the top level of a function, then it is reasonable to assume that users will expect this to occur for variables with type annotations and for constants.

Sam summarises that conditional declaration is controversial. We have an agreement that type expressions are compile-time constants. Herman wants very simple expressions, ones that don't allow function calls. This sparks discussion. Chris and Waldemar argue for general type expressions. Herman thinks this will create learning problems. Mike doesn't find Herman's argument compelling.

Rok asks if there are any differences between types introduced in the language and those from outside. The discussion rambles on. Herman could live with general type expressions, but states that in his opinion "it is ugly as hell".

Deliverables and Scheduling

Herman's attempt to cut down Waldemar's document didn't lead to anything that fitted together well. We get diverted into a discussion of document formats and what tools we will use for editing. Clayton reports that Word proved to be very costly for Bill Gibbons and eventually the document had to be fixed up by Microsoft as no one else had the requisite skills.

Waldemar thinks the bug is still in Word2000, but Rok says has been fixed in a service pack. Word caused problems with line numbering and section numbering. Perhaps this is caused by a corrupt document, otherwise we may need to identify the bug on MacWord and get it fixed.

Action: Rok will follow up the Word story and whether we can use MacWord on the edition 3 document safely.

Action: Dave agrees to contact people in W3C with practical experience in using XML for large specifications. Some of the issues include revision histories with change bars, special characters, annotations, cross references, spelling and grammar checking. Dave notes that converting XML to RTF is a well established route.

Action: Clayton will check with ECMA to see what exactly they need. For instance, can they accept XML or Word or some other format?

General WAP Discussion

Ted wants to know what he can take back to the WAP Forum. He in particularly concerned about schedules and deliverables. Clayton assures him that as the conduit to the WAP Forum he is free to take the information back.

Waldemar's stuff is in the Mozilla's open sources. ECMA process is not public. Dave notes that the web site is publically discoverable (it turns up in a search on Google).

We get into a discussion on what kinds of sections we can cut as opposed to a gradual process of compromise. Waldemar thinks we talked about cutting interfaces at last month's meeting. Sam questions the wisdom of cutting interfaces and wonders if there aren't some other areas that would be less painful to remove.

Action: Chris to post a summary of his understanding of where we got to in the discussion on interfaces.

We discuss how the WAP perspective will effect the nature of our discussions. One thing is that people will expect to use the idioms that they have learned on the Web, so it will be important to support existing ECMAScript mechanisms.

Dave thinks that the pressure on WAP to get to market may influence what ECMA TC39 chooses to focus on next. For instance, packages are part of WMLScript2 but not in ECMA 262 edition 3.

Ted explains that he thinks WAP would prefer as large a subset of edition 4 as possible. Nick says that for the next generation of mobile devices, implementing edition 3 is well within the bounds of possibility.

Nick says he has been pushed on performance of software implementation of floating point. Waldemar says that in Netscape's implementation most calculations use integers and they optimise for this.

Clayton says the a floating point implementation was about 6Kbytes. This also matches what Mike Cowlishaw reports for decimal arithmetic. Dave and Mike are collaborating on developing an Open Source C++ class for decimal arithmetic, which they hope will be of interest for the WAP work.

Louis likes the idea that implementations of subsets should fail gracefully on features that they don't support. Ted adds that subsetting along package lines makes the most sense. Subsetting the core semantics would host the programmers. Herman would like to see restrictions on eval e.g. to expressions without the ability to declare variables or classes etc.

Clayton runs through the rationale for the new features in edition 4.

People are asking for packages for such things as client side validation of forms. This leads to the idea of programming in the large and brings in versioning, classes, interfaces and types for ensuring robust operation.

Interest in using ECMAScript on the server leads to a design for a large statically compileable subset of the language.

The use of ECMAScript for application generation emphasizing component generation and glue seamlessly to other languages. This motivates machine types.

WAP - small working set, efficient transmission and simple compiler, this motivates restricting eval and the possibility of precompilation on the server.

Agenda for next meeting

We should review the document format issue assuming that the actions have been done and fed back via email in the interim.

Herman could annotate Waldemar's document via Word and make it available to the Group. Rok proposes prioritizing the features in Waldemar's spec as a basis for thinking about what we could choose to cut. Waldemar notes that we have done this several times before and doubts its effectiveness.

Herman volunteers to identify the major issues he feels are blocking progress. He would also like to see more preparatory materials prior to each meeting. He expects to be able to mail out his analysis in about a week's time. Waldemar will respond before leaving on his vacation.

Sam would like us to come to the next meeting with specific proposals. He wants the agenda to be hammered out one week before the meeting with people assigned to each topic.

Ted will report on the priorities for ECMAScript coming out of the WAP Forum's June meeting in Beverley Hills.

Herman lists some constraints that Waldemar could apply to revising the spec.