Since no one else has posted notes, I will. This is not meant to be a complete
summary; it's just the notable items that I happened to write down. These are
*not* minutes of the meeting.
- The current plan is to submit ES3.1 to a vote at the June 2009 ECMA General
Assembly. The successor is ES-Harmony and will come later. A suggestion was
made to insert another version in between ES3.1 and ES-Harmony which would be
essentially equivalent to ES3.1 in behavior but written in a more formal spec
language. This would not have much of a benefit to the users of the standard
and the suggestion was rescinded.
- We're still agreed that we will want two independent implementations of ES3.1
before submitting the standard to a vote. Mozilla will likely have one. MarkM
will ask the Chrome guys about implementing it.
- Test suite: The Mozilla test suite is used by Mozilla, V8, and others. It's
MPL-licensed which Microsoft doesn't like. Mozilla will look into what it will
take to relicensing it to an MIT-style license. One approach to avert
political problems would be for some or all of the test suite to become an ECMA
document to make it easier for Microsoft can read it.
- We pretty much agree on the ES3.1 features, but the writeup in the document
is still buggy and needs work, particularly chapters 8 and 10.
- In strict mode there is a strong desire to prohibit uses of <F.caller> and
<F.arguments> where <F> is a Function object of a function that has an active
stack frame, as well as uses of <arguments.caller>. It creates an interesting
dilemma in that these features are not in the ES3 spec, so how does one remove
something that doesn't officially exist? One possibility is to state that
implementations *don't* do this, which was Waldemar's preferred position, but
the committee thought that this was not strong enough because code that tried
to access these would read <undefined> instead of throwing an exception. We
reached consensus on requiring implementations to define on strict functions
<F.caller>, <F.arguments>, and <arguments.caller> with non-deletable,
non-writable properties that have getters that throw exceptions when read. An
open question is what happens if one uses the reflection API to extract the
exception-throwing getters: are they all == to each other?
- Is the Array <length> property a getter when viewed via the reflection API?
If it is, are the different getters == to each other? Not clear at this point.
Allen doesn't care, MarkM wants it fully specified, Waldemar wants closure
joining back iff it is unspecified and the committee was sympathetic to that.
- Minor Date language cleanup issues. Wording changes. Agreed to the <now>
method. Agreed to require that methods that return the current time return
non-decreasing values under normal operation (i.e. if someone doesn't manually
change the machine clock).
- We briefly reopened the discussion of whether <const> is in the language.
The resolution was that it is in (unless of course nobody does the work to
include it in the spec). We agreed that <const> should be written at the point
of initialization rather than have write-once semantics; the latter could be
subverted as in:
{
...
const x=2;
function f() {
return x;
}
function g() {
// possibly x = 5;
}
}
If g() runs first, then f() might return something other than 2!
An open issue is whether const violations should be compile or run-time errors.
Clearly some of them are undecidable and can only be reported at run-time, but
what about the clear-cut cases?
{
a = x;
const x = 2;
}
- <Object.clone> was proposed. Waldemar shot it down due to various technical
deficiencies and the committee agreed.
- A syntactic rule was proposed to disallow any statement following a <return>,
<break>, <continue>, or <throw> statement in order to cut down on errors.
Waldemar pointed out that this would fire for non-dead code such as:
if (x)
...
else
return z;
foo();
where foo() isn't dead at all. Other legitimate places to have statements are
after a <break> in a <switch>. There wasn't much desire to change its
semantics so that it would look for dead code (that would require specifying
whether ... can proceed or not), so it was dropped.
- We were wondering why ES4 had a version of <eval> that did not capture the
enclosing scope. This does not appear to be permitted by ES3, which requires
that <eval> either evaluate in the current scope or throw an EvalError.
- The contained <statement> inside a labeled statement should be a
<substatement> in the grammar.
- In strict mode, a variable reference inside a nested scope must not evaluate
to a Reference whose base is null rather than a Reference to a property of the
global object. The latter would prohibit legitimate references to Window.foo
inside a function.
- Discussion about syntax of <use strict> directive. Most favored option is
the string literal "use strict" or "use strict,xxxxx" where xxxxx are arbitrary
characters at the beginning of the program.
- The semantics of Function.bind were essentially broken and need to be
rewritten. We also changed its semantics so that bind works exactly as though
the additional arguments were supplied at the point of the call, which means
that you can use bound functions with both function calls and the <new>
operator and have them behave as expected.
- Dropped efforts to reflect the names of parameters. Many of the ones in the
ES3.1 spec have names that are convenient for the algorithm writeups but don't
make sense otherwise: <Object.defineProperty> would have the parameters ["O",
"P", "Attributes"]. This also wouldn't extend to the rest parameters that
we'll introduce in ES-Harmony, so it's premature to standardize it now.
11.9.3: Step 15 on is dead code.
Step 19 is dead code.
15.13.1.1: What's a 34 digit integer? For example, 7 is not a 34 digit
integer.
15.12.1: What does it mean to parse 1?
15.12.2: What does it mean to contain cycles? What if the cycle is filtered
out? What if the object modifies itself as it's being read (due to getters or
side effects from toJSON routines)?
DECIMAL AND IEEE 754-2008
Mike Cowlishaw gave a presentation about Decimal and the IEEE 754-2008 standard
which replaces IEEE 754-1985. New things in there (most of which apply to both
binary and decimal floating-point values) include:
- New 64 and 128-bit decimal types and 128-bit binary type. The decimal types
each have two incompatible representations.
- Hexadecimal float literals
- Round-to-nearest-ties-away-from-zero mode
- Fused multiply-add
- minnum and maxnum (min and max that ignore NaNs)
- Number-string conversions now must be correctly rounded. ES3 already
specified that.
- Classification routines (isNaN, isFinite, etc.)
- quantize and sameQuantum
- Signed NaNs
- 36 trigonometric and such functions which must be correctly rounded to the
last bit. Apparently that's now possible to do, although nobody has actually
done for the power function. Luckily these don't have to set the inexact flag
correctly ;-).
Most of the above are mandatory. Making things mandatory even where they don't
necessarily apply seems to be the culture of the IEEE 754 committee.
Deleted from IEEE 754:
- Some ways of detecting underflows
- Traps are no longer mandatory
Mike Cowlishaw published a decFloats C package under an MIT-style open source
license: http://speleotrove.com/decimal
Mike Cowlishaw's preferred semantics of Decimal keeps track of trailing zeroes
in some ways that several in the committee consider bizarre:
1.00 + 1 --> 2.00
1e12 - 1e12 --> 0e12
5 + 5 --> 10
1/.1 --> 1e1
1/3 - 1/3 --> 0e-34
The values 10 and 1e1 are operationally different. This causes problems for
array lookups where the index is converted to a string: a[1e4] and a[100*100]
would refer to different elements. IBM gave in on this point and we all agreed
to not track trailing zeros (i.e. distinguish among cohort members) at all in
ECMAScript.
The "m" decimal literal suffix is in for ES3.1. It's the only
non-downwards-compatible-with-existing-browsers syntax change in that spec.
The spec needs to be updated to include it.
We discussed and agreed that four of the Math routines (min, max, abs, round)
should work on both binary and decimal floats in the natural way. The other
ones can coerce to and return only binary floats.
Sam is implementing Decimal in V8 (and Mozilla?).
Waldemar reviewed the current writeup of Decimal and struggled to understand
it. We now agree on what the behavior should be, but pretty much every section
of the writeup needs to be corrected or rewritten. Sam will do the work and
Waldemar will review.
ES-HARMONY
We spent most of Friday on ES-Harmony, with a long discussion about the role of
types. We agreed that having types be symbols or badges ("interfaces") that
some classes can export and can be used to annotate variables and parameters
would be a good direction to follow. We got at least tentative agreement on:
- Types should be sound. If <a> has type T, and no one changes <a>, then <a>
should continue to have type T.
- There should be a mechanism for requesting a concrete type (instead of anyone
who claims to implement an interface) in situations that call for it. The
simplest way to do this would be to allow classes to be used as types (in
addition to interfaces), but that's still considered controversial. Other
possibilities include some way of "freezing" a badge. I hope we can make a bit
faster progress on this.
UPCOMING MEETINGS
(I assume that the first day of each meeting is for the secure scripting
subgroup.)
Nov 18-20, Royal Kona Resort, Hawaii (heh, in today's economy the hotels there
are cheaper than in Redmond)
Jan 27-29, Google Mountain View
Mar 24-26, Washington DC
Waldemar
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
