These notes cover:

ECMA TC39 meetings 23rd March 2000

Redmond, 23rd March 2000, hosted by Microsoft

Mike C - Decimal Arithmetic Proposal

Mike sent out a proposal in December for the changes needed to ECMA 262 to add decimal arithmetic. He summarises the broad choices open to us:

  1. Binary only
  2. Decimal with Infinity, Nan and minus zero.
  3. Pure Decimal + drop back/binary option
  4. Binary as now + Decimal Package
  5. Integer only profile (e.g. WMLScript)

Chris discusses numeric literals. Mike would like to discuss integers separately. Sam thinks that it may be interesting to consider allowing different combinations on different hardware platforms (e.g. WAP) and for different vendors. Once there are more than one of two options, it may make sense to leave things flexible.

Mike talks about the performance issues for (2). He claims that the cost of software emulation of decimal arithmetic is not important for typical scripts. It wouldn't be costly though for math intensive code e.g. MPEG decoding. For integers you can use an integer look aside for efficiency.

Rok asks about conversion issues when calling out to other languages or modules which don't support Decimal numbers. He notes that for Microsoft, floating point numbers don't need to be stored on the heap. Mike responds that you can represent Decimal numbers in 64 bits, although for ECMASCript he proposes a larger range which wouldn't fit into 64 bits. Chris notes that you aren't restricted to a single representation for decimal numbers within a given implementation.

Herman is concerned about backward compatibility issues. He would like to try out some tests to see what kinds of problems. He notes that this experiment is not going to be cheap.

Mike says that IBM will provide a Java based implementation as Open Source along with a suite of test cases. Dave says HP is going to make a C/C++ implementation available as OpenSource. The long term concern is to provide an effective set of test cases to check implementations against.

Mike talks about the ability to switch to binary or decimal on a module basis. He says this has proved to be very effective in practice. It avoids the need to scatter types everywhere.

Chris and Waldemar are not convinced. Mike asserts that Chris's expectations are not those of most users. In NetRex most users accept the default (decimal). Only expert users invoke the binary option, and then only as appropriate.

Clayton asks for Mike's experience for the cases where scripts or external code which use different choices for arithmetic. Mike responds that he hasn't seen people running into problems over a period of several years and large numbers of users.

We talk about round tripping across modules and languages. This in general needs to deal with conversions. Mike notes that even within IEEE arithmetic there are a set of flags that can effect round tripping.

Sam asks if we can reach a concensus about making the choice of arithmetic on a package? Waldemar says no.

For WAP a 9 digit representation that fits into 64 bit is fast and effective, says Mike.

Peter asks for a summary of why decimal arithmetic is valuable, compared for example with number formatting techniques. He thinks that if we need to explain two different number systems, we may be worse off that staying with the current approach. Mike argues vigorously against this.

Herman is inclined to go with Mike's proposal subject to the experiments to check on compatibility issues.

Chris and Mike argue about what people mean by 0.1 and 0.10. Mike says that in his experience people think of these differently. Chris is thinking mathematically when he considers these two numbers to be the same. Sam notes that we are not making forward progress.

Rok is concerned about loop indexes. He switches to consideration of compiling down to native arithmetic. If we really want to speed loop performance, we should provide a language construct, notes Mike. Herman is not sure that the loop performance issue is critical.

We try to narrow down our options.

We agree that there should be decimal and binary arithmetic. We have yet to decide how to switch, i.e. how the choice is exposed to the user.

Mike notes that virtually every company is now storing numbers in a textual form and not as binary numbers.

Mike proposes we back pocket the pure decimal option (altering the Number class in the standard to be based on decimals).

If we go for a combination of decimal and binary, and we see few compatibility issues, then we could revert to the pure decimal position, which incidentally would reduce the size of the specification.

Sam offers the possibility of IBM helping with implementation for an experiment. The obvious approach is to for IBM to help an experiment based upon Mozilla. Herman is concerned about Microsoft being able to conduct its experiments in a reasonable timescale.

Overloading

Waldemar was volunteered to talk about this. We think that study of the ways calls to other languages are handled may be useful in how we handled method overloading within ECMAScript.

Waldemar talks about Netscape's liveconnect mechanism for calling from JavaScript to Java. He says they look for:

  1. static/instance methods
  2. match on number of arguments passed/expected
  3. maximal match across arguments and methods using a weighting algorithm
  arg1 arg2 arg3
method1 good good fair
method2 fair poor good
method3 poor poor poor

Waldemar talks about the situation where a class supports two interfaces which in turn refine a third interface.

Herman says that the approach is inline with how VBScript handles method overloading.

Clayton says this can't be part of the ECMA spec since it is specific to calling Java. It could be in a non-normative section of the spec. Sam says we could include it normatively in a non-language specific way.

We talk about error messages and the ability in Java to use reflection to find hidden methods.

We agree to adopt the mechanisms in Scott Furman's draft as the basis for "function agreed".

The "Dollin Principle"

Peter's document on this was responded to by Chris, and Peter now thinks we are closer together than he previously thought.

Chris talks through his ideas for interface types as a means for preserving the principle.

class X implements interface I1;

var x = new X();
var i:I1 = x;

x.bar()
i.bar();

var y = i;

/* interface I2 refines I1 */

var i2:I2 = x;

var i1:I1 = i2;

Herman takes up the whiteboard marker and draws:

var a
var b:T
var c:D

a = b = c = obj

a.foo
b.foo
c.foo

a[x]

If obj implements T you can get performance wins for "a.foo" where "a" was declared as simply "var a" without a type annotation. Herman adds, he badly wants type inference to work. He describes his motivation.

Herman raises the issue of versioning and COM objects. He is concerned about the costs of accessing information about objects when these are not ECMAScript objects. He would like to restrict access to public members when the variable doesn't have a type.

Chris proposes that a["x"] could be restricted to public members only, so that:  a.x != a["x"]. With a.x you may have knowledge about the package etc. which you certainly don't with the array syntax.

Chris wants a multiple dispatch model. He would be okay with dispatching on the thing before the dot and then on the arguments.

Chris draws:

var b:T = new T();

...
b.foo()

/* where */
class S
  foo()

class T extends S
  foo()

class U extends T
  foo()

Herman says that he will find the vtable for T and use that to find the appropriate foo(), in this case the one defined in U. This happens, he says, via the v-table for T.

Herman wants to resolve the overloading at compile-time. Waldemar thinks you may need to do so at run-time. We then talked about how Java deals with this. Sam asks how Netscape's compiled Rhino works.

Chris says he sees static types as equivalent to exploiting partial evaluation using the dynamic rules. Herman says that optimizing this is difficult so he wants to provide further information.

Norris joins on the phone

Waldemar asks Norris how Rhino LiveConnect works. Norris says that each function call is resolved at run-time.

Waldemar says there are ways to define overloading that avoid this problem. Chris thanks Herman, and says that he now has a much better understanding of Herman's position. Chris is now in a position to construct for himself some tricky examples to work with.

Clayton states another principle:

It should be easy for programmers to write programs that can efficiently exploit static compilation.

He adds, it is not Netscape's goal to make every script statically compilable.

Herman doesn't want to have to construct the v-table on the fly.

Chris on Units

This is out of order, and actually took place after the business meeting.

Motivation for units: style sheets and complex numbers.

Chris runs through his ideas for syntax and semantics for units. He distinguishes between the stuff that is in the core language (literals and operator overloading), and what is in libraries. In essence the syntax is equivalent to calling a factory function with a string. We would prefer a uniform syntax. Sam proposes

(x + 1)*1feet

Chris can live with the simple notation consisting of a numeric literal followed by the name of a unit. Chris is also interested in the diagnostics that the compiler can produce. How does the compiler know that "foot" and "feet" are related?

Herman suggests the following syntax for unit declarations:

unit("cm") function foo(x, y) { ... }

Chris then turned to expressions over values with units. In some cases these expressions are something that can't be evaluated immediately. He proposes these are evaluated by a call to the function withbinding that supplies the context defining pixels or percentages etc.

We discuss the idea of using backquote to force a unit on something that would otherwise tokenize differently. This should work uniformly, e.g. "4`ft".

Waldemar and Chris will work on tidying up a proposal for the next meeting.

ECMA TC39 Business Meeting

Andrew says we need to talk about:

We have been asked to progress edition 3 to ISO JTC1. This doesn't need to involve the whole group. For edition 2, there was some 60 pages of comments from the ISO national bodies. We expect a lot less work for edition 4. Mike proposes we ask JTC1 to collate the comments before passing them onto us. We could expect to work through them in one day's hard work.

We then discussed the WAP/ECMA convergence plan. We are concerned about getting this work off the ground. We agree to get Asko to make a firm comitment to a meeting, to secure commitments from other companies, an editor and someone to chair.

Future meetings:

We then turned to timescales. Waldemar thinks that the current structure is inadequate. Herman, thinks this would also mean changing the text for the libraries. We are planning for "code complete" in September.

Sam volunteers to provide his cut at the table of contents for the edition 4 spec for May 4th. People should send Sam their input at least 2 weeks before hand. The aim is to prioritize the features by email before the May 4th meeting.

Waldemar commits to providing a document by Easter on member lookup and classes. Peter commits to provide a document by April 27th on classes and packages, describing what Microsoft will have implemented. Sam will bring up additional issues based upon notes from previous meetings.

Participants

Clayton Lewis Netscape clayton@netscape.com
waldemar Horwat Netscape waldemar@netscape,com
Mike McCabe Netscape mccabe@netscape.com
Peter Torr Microsoft ptorr@microsoft.com
Andrew Clinick Microsoft andrewc@microsoft.com
Herman Venter Microsoft hermanv@microsoft.com
Rok Yu Microsoft rokyu@microsoft.com
Mike Cowlishaw IBM ???
Sam Ruby IBM rubys@us.ibm.com
Chris Dollin HP kers@hplb.hpl.hp.com
Dave Raggett HP dsr@w3.org