Calls for nod of approval for current base document? Everyone seems happy. Question about changed wording on Slice mechanism. Was it a conscious choice? Not apparently.
As usual please send in suggested changes to Bill. Thanks to Bill for his hard work.
Should we do it in version 2? What bits should we do first? Andrew summarises: classes, units, types, modules. How do we prioritize?
Waldemar: Customer feedback - 1) DOM support and interoperability, 2) modularity (programming in the large). A bridge to style sheets. Higher performance will become an issue when ECMAScript becomes more central to layout.
HP's drivers - needs many of the key features for implementation of other things. Will HP keep Spice if ECMAScript evolves to add the corresponding features. Answer no.
Subgroup agreed to defer style rules to a separate track, and instead to focus on core lang issues.
Decided to add toLocaleString to the core language. A more full-featured I18N library when needed (not needed for low mem pda's etc). Very few things need to be in the core. Library can include formatting, parsing dates and numbers, string comparision, etc. Agreed to go with Unicode form C for normalization of strings (as a should not a must). We didn't feel it was necessary to provide support for normalization in the core, since this is under script author control.
Strings should be normalized for consistent behavior. Normalization is considered too expensive a function to include in the core language (large tables). Problem doesn't arise for for latin-1. Why not put this into a localization library which will be present pretty much everywhere.
For regexp we will add Unicode support. Some discussion about Japanese for identifiers. We want to allow small implementations e.g. on pda's and hence to move I18N features as much as possible to libraries. The library will be a hybrid of script and native code.
Plan to provide draft of what should be in the core in January 1999. Proposals for the library will come later. Looking for feedback from the group, e.g. on what's missing. We need to standardise the library support in this group. This work will be done on a longer timescale, but note that the core and the library definitions do interact.
January will be a 2 day meeting (Jan 11/12) with 1/2 day for each of the subgroups. Venue: Microsoft in Mountain View right by SGI [AC to organize]. Meeting to start at 10am.
Feb meeting dates? 19th Feb (one day meeting). GA in March.
ECMAScript component status? Deferred to this afternoon.
We need a chairman now that Gary Robertson has left Sun. Discussion deferred until Clayton arrives. Our next meeting will be a teleconference. Andrew C agreed to organise the teleconference.
See reverse of agenda [also on web site]. Spice items will be added. Mike concerned that the list is rather too long.
Closures agreed for V2.
I18N - core changes for V2 plus some description about directions for library (non-normative).
Spice related items - further discussion needed to set priorities. (Deferred until a bit later in the day.)
IBM would like to tighten up arithmetic to avoid rounding differences. Example of dividing 9 by 10 repeatedly. Java gives different rsult to ECMAScript implementations as do the NS and MS implementations of ECMAScript (albeit to a much lesser extent). Proposal is to introduce decimal arithmetic. See http://www2.hursley.ibm.com/decimal for details. IBM is also proposing this for Java. [ANSI X3.274-1996 standardizes decimal arithmetic]
Waldemar argues for rational arithmetic as subsuming decimal arithmetic. Dave suggests workaround is to round when printing numbers. Perhaps we have specified too high a precision for tostring(). Excel uses heuristics to determine how to round numbers.
Support for decimal arithmetic would allow reliable round-trips. Guy Steele's algorithm for rounding has same effect. Two different cases - tostring for machine where preserving precision is best and for people where nice numbers is important. Some interest in reviewing the definition of tostring.
IBM proposal is for a switch on the number class. What about modules with different switch values? Solution involves providing a context. Alternative is to add a new data type for decimal numbers.
Java interoperability. Some standard way to access and ideally to construct Java objects. How do you import externally defined objects?
Some mixed feelings: Implementation dependencies, and Java as a moving target. This ties into the work on modules and importing objects in a general way. Agreement that customers would like a clean interoperable way, but its perhaps too early to standardize.
CORBA is one way to handle general inter-language issues. Another is to define a sweet-spot for groups of languages. Perhaps the Spice ideas for classes and typing is related. This suggests that further work on these should be informed by the need for inter-language considerations.
We need to at least consider Java and COM. Perhaps that will constrain things enough to make quick progress. We need to provide a consistent syntax for accessing objects independent of which language the objects are imported from.
[break for lunch]
Caller (omitted from v1). Gone (says Waldemar). Removed from list of items.
conditional compilation/includes. The hope that the need for a preprocessor mechanism will be reduced by introducing a module/package mechanism. Concern that the language tag is host specific. Agreed: not ready for immediate standardization.
Array and Object literals. Agreed should be in V2.
function closures (same as we had this morning). Want an implicit closure class (explicit makes it hard for compilation).
reveal parent, proto. Parent is withdrawn. Do we want to expose the proto property? Leaning against it (dangerous flexibility, better to think through class mechanism which would subsume the need for access to proto), i.e., proto is deferred for now, and may morph into something else. Agreed - not in V2.
arguments object. Removed from V2, V1 functionality is fine.
exception handling. Agreement that its a good thing. Are we talking about try/catch/finally - yes. This is in the V2 spec already. Perhaps we ought to add catch guards as a placeholder for future? Agreement that we want multiple catch guards for V2.
toSource and object persistence. Issue is how to define how it works for different things, e.g. arrays. Is toSource the right way to go, say as compared with serialize and unserialize? Perhaps we ought to change to the goal to a means to provide persistence rather than a specific mechanism. Deferred for now.
Function.prototype.apply. Should be in V2, it is already in the proposal document, as is Function.prototype.call. See section 15.3.4.3.
binary object. Proposal from Borland for binary blobs, e.g. image data. Would be a new native type. It seems that this might be subsumed by classes. Scrubbed for now.
Date as proposed by Borland in 1997. Covers date scalar stuff. Subsumed by I18N subgroup discussions? Deferred for now.
Generic sequence operations on a string or an array. Borrowed from Python. Slice method provides an alternative and is already in V2. Example of sequence syntax [1..6] for first 6 chars. (call the functionality slice and splice syntax). Deferred for now.
Threading issues, e.g. locking. Concern that this is hard for most users to understand. Atomic operations - how are these revealed in the language. Agreement that the V2 spec needs to discuss atomic operations.
Should undefined literal not be reserved? If we introduce 'undefined' as a literal we will break things. You can't assign to undefined. Do we need a proposal? Agreement to make a small addition to the spec (undefined has initial value of undefined). Bill will add undefined as a property.
parse {int, float} step point result? What does it means? Scrubbed by executive decision. Ask for a new proposal.
toString extensions. Is this covered by tolocale? Scrubbed as it is handled by I18N work.
date to string (same - scrubbed as it is handled by I18N work).
toBoolean (object). Big thing for Shan. For COM objects, if object exists, return true - avoiding having to query the object. Scrubbed!
Hide proto.property. (Opposite of the reveal idea.) Scrubbed - subsumed by the class discussion.
meta object protocol (MOP). We might want something for reflection of class properties. Scrubbed.
package concept. same as modules - deferred to Spice discussion.
Mike proposes to refine the list in time for the teleconference next month.
We need a chairman of some form e.g. to handle GA. Why not make Clayton and Andrew into joint chairs? (The tasks are not too onerous). Action Clayton and Andrew to speak to higher ECMA levels to make it so.
Prompted by NetObjects anouncement. Andrew suggests we should make a decision one way or another. It would be nice to define a common mechanism for components for ECMAScript as for HTML components? Andrew says they are quite different, the latter are mostly HTML.
How should we take this forward. Clayton says its a separate formal subgroup of TC39. This group (meeting today) doesn't need to do anything. General agreement that the separate status should continue. It's still going, although making slow progress. Now have a replacement for the chair (replaces Karl Matzke of Sun).
Concerns about WMLScript - yet another subset of ECMAScript plus extensions (small subset with big extensions). It uses chunks from the ECMAScript spec and references it. But, the core classes are not extensible. They are namespaces for built-in functions. They also define a byte code format.
Mike to send Dave R a copy of the WMLScript spec.
Perhaps the right thing to do is to invite a WMLScript guy to talk at a future ECMAScript meeting. Or perhaps we should wait and see. Lets invite someone in March?
This session was led by Dave Raggett (me). I wrote the following observations after the meeting based upon my memory of the direction the discussion took and also the Spice subgroup meeting held in Bristol, England. Andrew C took notes which should be inserted here [tbd].
First, there is interest in moving ahead with adding support to ECMAScript for modules, classes, types and units, although the latter are rather new and may warrant deferring, given the desire to finalize the spec by June. The Spice subgroup will meet again in a teleconference will be held on Thursday December 3rd to discuss the ideas in more detail. [action Andrew Clinick to organize the teleconference]. The resulting proposals are to be presented to the full group in the January meeting.
To have a good chance of being accepted, proposals should avoid introducing new keywords other than those currently reserved in ECMA 262 - 2nd edition. This means modules will need to be defined using the keyword "package". A new proposal using "package" is sought. The proposal should account for intra and inter language issues accross module boundaries, especially for Java, C++ and COM.
It now seems very likely that classes will need to follow similar semantics to Java, i.e., single inheritance and classes defining name scopes. We won't be able to add "slot", but "extends", "implements", "public", "private" and "protected" are fine. A nicely written proposal along these lines would be very helpful. Classes should be something useable by both novices and experienced programmers.
The group showed a willingness to accept units provided the proposal is based on top of the new class mechanism. In essence 3cm would be syntactic sugar for calling a constructor for the "cm" class which is derived from the "length" superclass and in turn from the "dimension" class. This approach presupposes operator overloading based upon all the arguments. An expression such as 3cm+20% is returned as an object that can later be used to compute a value (in pixels) when given an appropriate context.
The group raised concerns about the scope for contexts which need to be answered in any new proposal. I think the approach can take advantage of the rewrite rules proposed by HP for relating values in different units. This would be a matter of defining an appropriate method for the plus operator which is called when its arguments are both instances of the dimension class. Ideally, this means providing a means for programmers to define overloaded operators and to import systems of units from libraries.
In essence, units would impact ECMAScript in two ways: the syntactic sugar for calling constructors (3cm) and the means to write functions for overloading arithmetic operators. Overloading involves the same machinery as function dispatch on multiple arguments.
Any comments on the status document? No.
escape(string), unescape(string) now non-normative. Agreed. Bill to amend the spec. (URL escapes as per discussion with W3C)
Array.prototype.concat, push and shift. This is a rewrite of concat that attempts to test if something is array before proceeding. Other objects are just inserted as items in the array. Tightening up of semantics for sparse arrays to avoid interoperability problems possible with the V1 spec. (a proposed rewording was circulated and we all paused to read it through)
Question on sort: wording implies sort actually exists. Assume that this isn't the case. Answer yes.
Push and Pop - no changed needed. Agreed to move the changes for this and arrays into the spec and to update the status doc accordingly.
slice and splice. Changes involve removing an ambiguity and renumbering the steps of the algorithm. Move to content agreed.
Regular expressions. Following from last meeting, a revised proposal was circulated. The changes involve the role of line terminators. It looks like the proposal needs some polishing. Please report problems by email. Our intention is to match Perl's regexp semantics as closely as possible.
We would like to include Perl5 regexp changes before we move to complete status. This basically involves adding in some text on flags.
Lets get a revised proposal for the text in time for the teleconference with a view to moving it to text agreed.
Other small changes - adding Unicode classes to regexp strings. To be considered separately.
For Dec phone call, a new futures list by next week. The text for the regexp stuff, and anything else for the GA (which will occur a week after the phone call).
new proposal for allowing unicode in identifiers. Will be sent to list and added to website.
Spice subgroup to hold a phone conference in the 1st week of December.
For January meeting (2 days). To spend 1/2 day on i18n, and another 1/2 day on spice, with the remaining day on general review of current work items on the status document.
Errors and exceptions. Want to keep the types and their names and possibly the functions, but we would like to wait until more progress has been made on classes.
Persistence (toSource) [WG] and Sharp variables [BE]. General agreement that sharp variables are not the way to go. Sharp variables are moved to the deferred list. Persistence in general remains on the list for V2.
Grammar issues. (semicolon insertion etc) - fold into Spice discussions.
Types (for exceptions) Fold into Spice discussions.
Closures are to be discussed at January meeting. Array and Object literals look pretty good now. Bill will revise the proposal document for folding into the spec once we are ready to do so. We should go through the same process for the regexp spec.
Discussion about 08 (leading 0 should treat this as Octal, but implementations treat this as 8 to base 10). Perhaps this can be added to the spec under deprecated topics.
People tend to distinguish between run-time errors and exceptions they throw. Concern to avoid interoperability problems between implementations. Prefer to reserve parameters to error constructor for future work. But Microsoft's implementation already uses parameters in their IE5 beta. Netscape doesn't want to talk about error numbers in the spec.
Issues for passing exceptions across language boundaries. The type hierarchy for exceptions only coincides for the system exceptions. This will be effected by work on modules (packages) for ECMAScript.
Concerns about having different exception type hierarchies in implementations shipped before V2 is done. The hope is that error isn't the parent class of user thrown exceptions. Some evidence that this is ok. Microsoft's current implementation doesn't have an 'exception' class.
Are units typed? Definitive answer is maybe. Is context required for evaluating expressions with units? Yes, but there is a default context. What about scoping and contexts? Answer: more work is needed. Mike notes that it may be useful to look at the decimal arithmetic proposal which covers scoping nicely. Does the units string totally identify the unit or is there a scope? Chris answers: it depends on the module system we end up with.
The proposal involves rewrite rules that determine which units an expression returns, e.g. 6in+2ft, is this 2.5ft or 30in? Chris says 5in+10px yields a pending value which when referred to later on when the context is clear is able to return a length value.
Can't units be treated as objects and subclassed to define new units? The compiler could take the suffix notation and call the appropriate constructors. We would need operator overloading and support for deferred values (these could in turn be unit values). Some concerns about scoping remain. This approach exploits the general object mechanism rather than some generic rewrite mechanism. Fundamental classes are dimensions.
Want consistent proposal that covers equality, toString as well as arithmetic operators. Want to see regular mathematical concepts addressed, e.g. commutivity, associativity etc. Are units immutable?
Equality might return yes, no or can't tell yet. Chris proposes work on a more detailed proposal which is less terse and hence easier to understand.
end of meeting