Wednesday TC39 ES3.1 notes

# Waldemar Horwat (17 years ago)

Here are my notes on today's TC39 ES3.1 discussions. We resolved a lot of issues, which I hope I recorded all below.

Waldemar

John and Allen want a flag date to issue s press release about a candidate spec. Change control may be locked down after that? Waldemar: ECMA should not be the editor. Changes need to be made by a technically savvy editor. Waldemar's concern: document has been evolving too quickly, and each time he reviews the document he needs to re-read the whole thing which takes a long time. Proposed two levels of change bars after a settle-down date, with changes from ES3 -> settle-down date tracked with a different color from changes settle-down date -> head revision.

New schedule: March 1st: proposed candidate specification sometome between March and May: Candidate specification Web testing through July Wording/typo/etc. fixing through September Submitted to December GA

Need to remove ToObject from base when making references: function foo() {return this} (in strict mode) foo.call(3) -> returns a primitive (i.e. non-wrapped) 3

String.prototype.foo = foo "bar".foo() -> needs to return a primitive too

Question: what if the function does: function foo() {this.x = 5} Answer: in non-strict mode, works as before. In strict mode, throws an exception due to an attempt to set a property on a primitive.

Use a ::: instead of : grammar to describe use directive syntax in chapter 14. There are other examples of such usage in chapter 15 that can be used as a guideline. Also should describe white space using the lexar grammar, not the syntactic grammar.

[[Class]] == "String", "Date", "RegExp", "Array", "Function", ... Need [[IsArray]]? Is [[Class]] trustworthy? Should we enforce constraints on host objects of these classes? Strawman: Host objects should only be able to do what native objects can do -- doesn't work for host functions that can access data outside the ECMAScript environment. Many of the invariants are enforced by native constructors' behavior, not by constraints on native objects. Proposal:

Change instances of "is an Array object" to "[[Class]] is "Array"", etc.
Write specifications on invariants that host objects must ssatisfy in order to use one of the above [[Class]] values. Who will do it?

Dealing with multiple global objects: Informative annex to 3.1? A Technical Report would be more appropriate.

Should bind curry over [[Construct]]?

Agreed to use option 2 from Allen's list: bind will curry over [[Call]] and [[Construct]]. The bound closure will not have a prototype property -- [[Construct]] will use the prototype of the original function just as it normally would.

Should bind result in a frozen function?

Agreed that bind does not result in a frozen function.

When is eval direct? Strict?

Agreed to keep the current two conditions of a direct call named "eval" and the function actually evaluating to the built-in eval function.
Agreed to disallow the use of "eval" as the name of a local variable, function parameter, etc. in strict mode.
Agreed that eval is strict if and only if the eval'd string starts with a use directive.
Agreed that indirect eval calls will use their own little private scope for newly introduced bindings in strict mode (as determined by whether the eval'd string starts with a use directive), even if they're called at the global level.

Should apply be specified like an array generic?

Agreed that it should be generic. This will also make it explicit what happens if there are holes in an array.

Should numerically named properties of strings be enumerable?

Yes.

Parse time error reporting ("strict")

"detection does not require program execution" is too vague. Agreed to retain the "must" as long as individual cases are listed instead of "detection does not require program execution".

Regexp lookahead

Rejected the ticket. Rejecting quantifiers syntactically would be a breaking change and make grammar syntax more complicated. There is a use for quantifiers after lookaheads -- executing a quantifier zero times is different from executing it once, and the differences can be observed via capturing parentheses.

Name properties of getter/setter functions defined in object literals.

Property values for function <name> are "get <name>", "set <name>", "bind <name>". They do not show up on the scope chain.

Multiline comments: break/* */foo; See bugs.ecmascript.org/ticket/414

Agreed to retain the specified ECMAScript behavior: a multiline comment counts as if it were a line terminator.

11.1.4: Replace [[Put]] of length with DefineOwnProperty. Generic array algorithms will continue to be done using [[Get]] and [[Put]] (this is important for folks who define length properties as getter-setter pairs).

JSON throws a SyntaxError when it detects a problem with the input. This is the first instance of throwing a SyntaxError based on what's typically user input data. Suggestions were made for using a FormatError or JSONError. Waldemar reluctantly relented to reach consensus to keep SyntaxError, mainly due to compatibility with existing JSON libraries. This means that users who catch SyntaxErrors hoping to catch JSON errors will catch things that are not user data errors as well if, for example, the ECMAScript program constructs faulty regular expressions or eval's code with syntax errors.

What causes the arguments object to get un-joined with local argument variables?

Allen's current approach (changing enumerability or configurability doesn't matter, changing value breaks joining) seems like the right approach.
Agreed that in strict mode there is no joining of arguments objects to local variables.
Agreed that arguments objects are not frozen in strict mode. There are important use cases for mutating them, such as stripping off initial arguments using shift and passing the rest to another function.

Dinner 6:30pm at Pezzella's.

Here are my notes on today's TC39 ES3.1 discussions.  We resolved a lot of issues, which I hope I recorded all below.

    Waldemar


John and Allen want a flag date to issue s press release about a candidate spec.  Change control may be locked down after that?
Waldemar:  ECMA should not be the editor.  Changes need to be made by a technically savvy editor.
Waldemar's concern:  document has been evolving too quickly, and each time he reviews the document he needs to re-read the whole thing which takes a long time.  Proposed two levels of change bars after a settle-down date, with changes from ES3 -> settle-down date tracked with a different color from changes settle-down date -> head revision.

New schedule:
March 1st: proposed candidate specification
sometome between March and May:  Candidate specification
Web testing through July
Wording/typo/etc. fixing through September
Submitted to December GA

Need to remove ToObject from base when making references:
function foo() {return this}  (in strict mode)
foo.call(3) -> returns a primitive (i.e. non-wrapped) 3
String.prototype.foo = foo
"bar".foo() -> needs to return a primitive too

Question:  what if the function does:
function foo() {this.x = 5}
Answer:  in non-strict mode, works as before.  In strict mode, throws an exception due to an attempt to set a property on a primitive.

Use a ::: instead of : grammar to describe use directive syntax in chapter 14.  There are other examples of such usage in chapter 15 that can be used as a guideline.  Also should describe white space using the lexar grammar, not the syntactic grammar.

[[Class]] == "String", "Date", "RegExp", "Array", "Function", ...
Need [[IsArray]]?  Is [[Class]] trustworthy?
Should we enforce constraints on host objects of these classes?
Strawman:  Host objects should only be able to do what native objects can do -- doesn't work for host functions that can access data outside the ECMAScript environment.
Many of the invariants are enforced by native constructors' behavior, not by constraints on native objects.
Proposal:
+ Change instances of "is an Array object" to "[[Class]] is "Array"", etc.
+ Write specifications on invariants that host objects must ssatisfy in order to use one of the above [[Class]] values.  Who will do it?

Dealing with multiple global objects:  Informative annex to 3.1?  A Technical Report would be more appropriate.

Should bind curry over [[Construct]]?
- Agreed to use option 2 from Allen's list:  bind will curry over [[Call]] and [[Construct]].  The bound closure will not have a prototype property -- [[Construct]] will use the prototype of the original function just as it normally would.

Should bind result in a frozen function?
- Agreed that bind does not result in a frozen function.

When is eval direct?  Strict?
- Agreed to keep the current two conditions of a direct call named "eval" and the function actually evaluating to the built-in eval function.
- Agreed to disallow the use of "eval" as the name of a local variable, function parameter, etc. in strict mode.
- Agreed that eval is strict if and only if the eval'd string starts with a use directive.
- Agreed that indirect eval calls will use their own little private scope for newly introduced bindings in strict mode (as determined by whether the eval'd string starts with a use directive), even if they're called at the global level.

Should apply be specified like an array generic?
- Agreed that it should be generic.  This will also make it explicit what happens if there are holes in an array.

Should numerically named properties of strings be enumerable?
- Yes.

Parse time error reporting ("strict")
- "detection does not require program execution" is too vague.  Agreed to retain the "must" as long as individual cases are listed instead of "detection does not require program execution".

Regexp lookahead
- Rejected the ticket.  Rejecting quantifiers syntactically would be a breaking change and make grammar syntax more complicated.  There is a use for quantifiers after lookaheads -- executing a quantifier zero times is different from executing it once, and the differences can be observed via capturing parentheses.

Name properties of getter/setter functions defined in object literals.
- Property values for function <name> are "get <name>", "set <name>", "bind <name>".  They do not show up on the scope chain.

Multiline comments:
break/*
*/foo;
See http://bugs.ecmascript.org/ticket/414
- Agreed to retain the specified ECMAScript behavior:  a multiline comment counts as if it were a line terminator.

11.1.4:  Replace [[Put]] of length with DefineOwnProperty.  Generic array algorithms will continue to be done using [[Get]] and [[Put]] (this is important for folks who define length properties as getter-setter pairs).

JSON throws a SyntaxError when it detects a problem with the input.  This is the first instance of throwing a SyntaxError based on what's typically user input data.  Suggestions were made for using a FormatError or JSONError.  Waldemar reluctantly relented to reach consensus to keep SyntaxError, mainly due to compatibility with existing JSON libraries.  This means that users who catch SyntaxErrors hoping to catch JSON errors will catch things that are not user data errors as well if, for example, the ECMAScript program constructs faulty regular expressions or eval's code with syntax errors.

What causes the arguments object to get un-joined with local argument variables?
- Allen's current approach (changing enumerability or configurability doesn't matter, changing value breaks joining) seems like the right approach.
- Agreed that in strict mode there is no joining of arguments objects to local variables.
- Agreed that arguments objects are *not* frozen in strict mode.  There are important use cases for mutating them, such as stripping off initial arguments using shift and passing the rest to another function.

Dinner 6:30pm at Pezzella's.

# Mark Miller (17 years ago)

Great capture! Minor corrections below. Each checked with Waldemar before sending.

On Wed, Jan 28, 2009 at 5:05 PM, Waldemar Horwat <waldemar at google.com> wrote:

Should bind curry over [[Construct]]?

Agreed to use option 2 from Allen's list: bind will curry over [[Call]] and [[Construct]]. The bound closure will not have a prototype property -- [[Construct]] will use the prototype of the original function just as it normally would.

As will [[HasInstance]], which is used by instanceof.

When is eval direct? Strict?

Agreed that eval is strict if and only if the eval'd string starts with a use directive.

That description applies to indirect eval. For direct eval, it's also strict if called from strict code.

Great capture! Minor corrections below. Each checked with Waldemar
before sending.

On Wed, Jan 28, 2009 at 5:05 PM, Waldemar Horwat <waldemar at google.com> wrote:
> Should bind curry over [[Construct]]?
> - Agreed to use option 2 from Allen's list:  bind will curry over [[Call]]
> and [[Construct]].  The bound closure will not have a prototype property --
> [[Construct]] will use the prototype of the original function just as it
> normally would.

As will [[HasInstance]], which is used by instanceof.

> When is eval direct?  Strict?
> - Agreed that eval is strict if and only if the eval'd string starts with a
> use directive.

That description applies to indirect eval. For direct eval, it's also
strict if called from strict code.

-- 

    Cheers,
    --MarkM