Initial comments on Kona draft
More comments.
Waldemar
11.1.5: This means that I can override a getter with a value property or specify two getters for the same property even in strict mode. We had agreed that strict mode disallowed such things.
11.2.1: "where <identifier-name-string> is a string literal containing the same sequence of characters as the IdentifierName.": The meaning is ambiguous in the presence of escape codes.
11.3.1, 11.3.2: All four of the return statemets are wrong in different ways. Some return the preincremented value. Some return an lvalue instead of an rvalue.
11.5: What's the corresponding Decimal operation? There are a bunch of different remainder options.
11.8.5: You're treating Unicode character codes as Decimal numbers. Which characters have Unicode numbers that are Numbers, and which ones have Unicode numbers that are Decimals?
If you fix this and apply the same contagion rules as for +, -, *, etc., then you'll have the issue that 1e-400m > 0m but 1e-400m > 0 is false. The contagion rules need rethinking.
11.9.3: The contagion here is from Number to Decimal. This is inconsistent with +, -, *, etc., where the contagion is from Decimal to Number. It should be the same for all arithmetic operations.
11.9.6: Don't need to call ToDecimal on values that are already Decimals.
11.13.1.1: The strict mode restrictions are ambiguous. What happens in this case, where g does not exist?
g = (function(){throw "foo"})();
What about this?
g = eval("var g = 5; 2");
Waldemar Horwat wrote:
7.8.3: This states that decimal literals may be rounded to 20 significant digits. Is that what we want?
That's a bug.
8.5: "The Decimal type has exactly 10^34*12288+3 values". I don't think this is correct. How did you arrive at this figure?
Mantissa has 34 digits Exponent can range from -6144 to 6143 NaN, +Infinity, -Infinity
Oversight: sign would double the number of values.
There are not ten times as many denormalized Decimal values as there are normalized Decimal values. All of the Decimal number counts in this section appear suspect.
There should be approximately 9 times as many... values with a non-zero mantissa that end with a digit of 0 as compared to mantissas which end in a non-zero value.
Why do we need to distinguish Decimal denorms anyway? The concept is not used anywhere in the document.
Do we need to distinguish binary floating point denorms? Dropping both would make me happy.
Fix grammar and spelling errors.
9: Decimal support broken in most of the tables.
Bug.
9.3: ToDecimal on a Number gives the Number unchanged?
ToNumber on a Decimal is not defined.
Bug.
9.8: ToString on a Decimal is not defined in the table.
The algorithm only works on Number values. +0, -0, etc. are Number values, not Decimal values. Also, it internally references conversions to Numbers.
Bugs.
9.3.1: ToDecimal on a string results in a Number. Also, it optionally drops significant digits after the 20th.
Bug.
11.3.1, 11.3.2: All four of the return statemets are wrong in different ways. Some return the preincremented value. Some return an lvalue instead of an rvalue.
Others have already noted this. David-Sarah has proposed new wording.
11.5: What's the corresponding Decimal operation? There are a bunch of different remainder options.
Should specify roundTowardZero. Good catch.
11.8.5: Status:
You're treating Unicode character codes as Decimal numbers. Which characters have Unicode numbers that are Numbers, and which ones have Unicode numbers that are Decimals?
I don't follow. If either value is of type Decimal, both are converted to Decimal, and the results are then compared.
If you fix this and apply the same contagion rules as for +, -, *, etc., then you'll have the issue that 1e-400m > 0m but 1e-400m > 0 is false.
The contagion rules need rethinking.
Again, I don't follow. The intent is that in the latter case, the binary 0 is first converted to decimal prior to the comparison.
11.9.3: The contagion here is from Number to Decimal. This is inconsistent with +, -, *, etc., where the contagion is from Decimal to Number. It should be the same for all arithmetic operations.
The contagion should consistently be from Number to Decimal. I distinctly remember making this change this time, but double checking what I sent to Pratap, it seems like the version of the document that I sent him did not include this change. sigh
To be clear, step 5 in the binary operators should read "5. If Type(Result(2)) is Decimal or Type(Result(4)) is Decimal, then", substituting "or" for "and" in the expression.
11.9.6: Don't need to call ToDecimal on values that are already Decimals.
Agreed.
- Sam Ruby
Sam Ruby wrote:
Waldemar Horwat wrote:
11.9.3: The contagion here is from Number to Decimal. This is inconsistent with +, -, *, etc., where the contagion is from Decimal to Number. It should be the same for all arithmetic operations.
The contagion should consistently be from Number to Decimal. I distinctly remember making this change this time, but double checking what I sent to Pratap, it seems like the version of the document that I sent him did not include this change. sigh
To be clear, step 5 in the binary operators should read "5. If Type(Result(2)) is Decimal or Type(Result(4)) is Decimal, then", substituting "or" for "and" in the expression.
(I assume we are talking about sections 11.5, 11.6.1, and 11.6.2.)
That doesn't work. Step 5a in each of these algorithms assumes that both arguments are decimal values. You need something like:
- If Type(Result(2)) is Decimal or Type(Result(4)) is Decimal, then a. Call ToDecimal(Result(2)). b. Call ToDecimal(Result(4)). c. Perform <whatever operation> as defined in IEEE 754-2008 with arguments Result(5a) and Result(5b). d. Return Result(5c).
Of course ToDecimal must be defined as the identity function on decimal values.
However, it is not clear to me that the resulting behaviour is consistent in the case of binary '+' (section 11.6.1): string + number and number + string return a string, but string + decimal and decimal + string would return a decimal.
The least inconsistent option that I can see (that is still compatible with ES3) would be to move step 5 as defined above just before the call to ToNumber in step 9.
Another issue I've just spotted is that Decimal objects do not behave analogously to Number objects: ToNumber calls ToPrimitive which does unwrapping, but the checks for decimal arguments only check that the Type is Decimal, and do not unwrap. This makes Decimal objects even more useless than the other wrapper objects.
Incidentally, there is no such thing as an "addition method", "subtraction method", etc. in IEEE 754-2008. "Method" here is an ECMAScript term.
Re:
-----Original Message----- From: es-discuss-bounces at mozilla.org [mailto:es-discuss- bounces at mozilla.org] On Behalf Of Waldemar Horwat Sent: Friday, November 14, 2008 2:00 PM To: es-discuss Subject: Initial comments on Kona draft
Here are my preliminary comments. I haven't reviewed the entire draft yet.
Waldemar
Overall: With "const" missing, the changes to chapter 8 for attribute description become premature standardization and should be cut. The problem is that these changes are likely to be incompatible with ES- Harmony for the same reasons that cut "const". Without "const" we have no way of testing this, and I would not support issuing a standard only to have to say "oops" a few months later.
Could you elaborate? The majority of attribute related changes in chapter 8 are motivated by the reification of property attributes via Object.getOwnProptertyDescript and Object.defineProperty. It don't see where you are connecting them to "const". One the other hand, if you had said chapter 10 I might see where you were coming from
Here are my preliminary comments. I haven't reviewed the entire draft yet.
Overall: With "const" missing, the changes to chapter 8 for attribute description become premature standardization and should be cut. The problem is that these changes are likely to be incompatible with ES-Harmony for the same reasons that cut "const". Without "const" we have no way of testing this, and I would not support issuing a standard only to have to say "oops" a few months later.
5.2: "step my specify"
7.1: "format control characters may be used in identifiers, ...": No they can't, according to section 7.6.
7.3: "except that line terminators that are preceded by an escape sequence may occur": "preceded" is not thw right meaning here. "part of"?
7.3: The production LineTerminator :: ... | <CR> | <CR><LF>
is ambiguous. Probably the simplest fix is to change it to: LineTerminator :: ... | <CR> [lookahead isn't <LF>] | <CR><LF>
Even then having <CR><LF> there causes trouble for things like its use in 15.10.2.6, 15.10.2.8, and 15.10.2.12. It's not clear what we want there.
7.5: Token :: ReservedWord | Identifier | IdentifierName doesn't make sense
7.8.3: The MV of NumericLiteral :: DecimalLiteral m is not defined.
7.8.3: This states that decimal literals may be rounded to 20 significant digits. Is that what we want?
7.8.4: "All Unicode characters may appear literally in a string literal except for the closing quote character, backslash, carriage return, and line feed. Any character may appear in the form of an escape sequence.": This is wrong about the other line terminators.
8: Can Property Descriptors and Property Identifiers be stored as user-visible properties of objects? The last sentence seems to imply that they can.
8.5: "The Decimal type has exactly 10^34*12288+3 values". I don't think this is correct. How did you arrive at this figure?
There are not ten times as many denormalized Decimal values as there are normalized Decimal values. All of the Decimal number counts in this section appear suspect.
Why do we need to distinguish Decimal denorms anyway? The concept is not used anywhere in the document.
Fix grammar and spelling errors.
8.6 to the end of chapter 8: Cut all the changes or bring back "const". I have plenty of specific bug comments on these, but the whole exercise is now moot.
8.10: The nomenclature is too inconsistent for me to be able to readily make sense out of this at this time. Sometimes you refer to property descriptor properties as "writable" (as in "{value: 42, writable: false, configurable: true}", and sometimes as "[[Writable]]" (as in "Desc.[[Writable]]" in 8.10.2). Therefore these are two different things just as x.prototype and x.[[Prototype]] are different?
Also, Desc.[[Writable]] doesn't make sense because there is no such internal property listed in the table of all internal properties used in this specification in 8.6.2.
A big problem that must be addressed and which I've mentioned several times before is that the data types from 8.10 are used in earlier sections of chapter 8 before they are defined here. I can't figure out which order to read this chapter in, as text from 8.10 subtly modifies the interpretation of 8.6.2. Solving this problem by moving this content to or near 8.6.2 would help solve the others as well.
Can a Property Descriptor include both [[setter]] and [[value]] fields? 8.10 is ambiguous on that.
9: Decimal support broken in most of the tables.
9.3: ToDecimal on a Number gives the Number unchanged?
ToNumber on a Decimal is not defined.
9.8: ToString on a Decimal is not defined in the table.
The algorithm only works on Number values. +0, -0, etc. are Number values, not Decimal values. Also, it internally references conversions to Numbers.
9.3.1: ToDecimal on a string results in a Number. Also, it optionally drops significant digits after the 20th.
10.2: "functrions"
10.2.1: "binding can not be set throw a TypeError exception": Missing comma.
10.2.1.1: "a ECMAScrpt": a -> an and fix spelling error
"A declarative environment record binding the set of identifiers defined by the declarations contained within its scope.": Not a sentence.
10.2.1.1.x: Be consistent about spaces before the opening parenthesis of formal parameters.
10.2.1.1.6: "The S argument is ignored because stict mode deoes not change the meaning of setting bindings in declarative environment records have .": Ah, that's what "S" is for? You didn't explain this earlier when S was first mentioned in the other methods. Also, fix grammar errors.
10.2.1.2.x: Same comments as above. Also lots of typos in various places.
10.2.1.2.1: This will mean that having bindings in the prototype will prevent one from building ones in the leaf object.
10.2.1.2.4: "of it's associated ": it's -> its
"4. If Result(3) is false or the binding for N in Result(1) is an uninitialized immutable binding, then": What's an uninitialized immutable binding here? Result(3) is an object, not an environment. Objects have properties, not bindings.
10.2.1.2.5: This will always error out in DefineOwnProperty.
10.2.1.2.6: "3. If the binding for N in Result(1) is a mutable binding, then": What is a mutable binding? Result(1) is an object, not an environment.
"4. Else this must be an attempt to change the value of an immutable binding so throw a TypeError exception.": This doesn't follow. For example, just because Result(1) has no binding doesn't mean that its prototype doesn't.
10.2.2.1: "called with a lexical environment lex, identifier string, name, and boolan flag strict the following steps are performed": Due to several grammar errors (an extra comma and a missing one) this doesn't mean what it's supposed to.
10.2.2.x: "is call" -> "is called". Lots of other typos as well.
10.2.2.4: There is no current lexical environment bound around the declaration of PopEnvironnmentRecord.
10.3: "to tract the execution"
What is VariableEnvironment for? It's never used in the spec, except for a mention in 12.2 which is a bug and shouldn't be there.
10.3.2: Can't do the arguments object this way. It's incompatible with ES3 and current practice for multiple arguments sharing the same name. You also don't want users extracting the getters and setters out of the arguments array, etc. Also, the notion of scope in which the getters and setters are eval'd is fuzzy at best and can cause problems if other definitions ever shadow the parameter names.
10.3.3: "Variables and functions declared in ECMAScript code evaluate in the execution context are added as bindings in the that environment record." Huh?
"1. Let env be the running execution context's VariableEnvironment." How do those get created? Section 10.4 should come first.
10.4: This is still confusing. What creates execution contexts? There is no such step in the algorithms here.
12.2: This breaks ES3 and existing practice. Consider with(o) {var x = 3} if o.x exists and has the value 7. This code currently sets o.x to 3; the proposed change would leave it at 7.
13: "code code"
14: The syntax of the use strict directive is incompatible with the lexer grammar. There is no such separate token. What happens if someone escapes a character within the use strict directive token? The spaces before "use" and at the end are mandatory? Is it mandatory that the semicolon follow without an intervening space? How does the semicolon interact with semicolon insertion?
Strict directives are ambiguous with statements.
There should be no "opt" after UseStrictDirective's definition.
Here are my preliminary comments. I haven't reviewed the entire draft yet. Waldemar Overall: With "const" missing, the changes to chapter 8 for attribute description become premature standardization and should be cut. The problem is that these changes are likely to be incompatible with ES-Harmony for the same reasons that cut "const". Without "const" we have no way of testing this, and I would not support issuing a standard only to have to say "oops" a few months later. 5.2: "step my specify" 7.1: "format control characters may be used in identifiers, ...": No they can't, according to section 7.6. 7.3: "except that line terminators that are preceded by an escape sequence may occur": "preceded" is not thw right meaning here. "part of"? 7.3: The production LineTerminator :: ... | <CR> | <CR><LF> is ambiguous. Probably the simplest fix is to change it to: LineTerminator :: ... | <CR> [lookahead isn't <LF>] | <CR><LF> Even then having <CR><LF> there causes trouble for things like its use in 15.10.2.6, 15.10.2.8, and 15.10.2.12. It's not clear what we want there. 7.5: Token :: ReservedWord | Identifier | IdentifierName doesn't make sense 7.8.3: The MV of NumericLiteral :: DecimalLiteral m is not defined. 7.8.3: This states that decimal literals may be rounded to 20 significant digits. Is that what we want? 7.8.4: "All Unicode characters may appear literally in a string literal except for the closing quote character, backslash, carriage return, and line feed. Any character may appear in the form of an escape sequence.": This is wrong about the other line terminators. 8: Can Property Descriptors and Property Identifiers be stored as user-visible properties of objects? The last sentence seems to imply that they can. 8.5: "The Decimal type has exactly 10^34*12288+3 values". I don't think this is correct. How did you arrive at this figure? There are not ten times as many denormalized Decimal values as there are normalized Decimal values. All of the Decimal number counts in this section appear suspect. Why do we need to distinguish Decimal denorms anyway? The concept is not used anywhere in the document. Fix grammar and spelling errors. 8.6 to the end of chapter 8: Cut all the changes or bring back "const". I have plenty of specific bug comments on these, but the whole exercise is now moot. 8.10: The nomenclature is too inconsistent for me to be able to readily make sense out of this at this time. Sometimes you refer to property descriptor properties as "writable" (as in "{value: 42, writable: false, configurable: true}", and sometimes as "[[Writable]]" (as in "Desc.[[Writable]]" in 8.10.2). Therefore these are two different things just as x.prototype and x.[[Prototype]] are different? Also, Desc.[[Writable]] doesn't make sense because there is no such internal property listed in the table of all internal properties used in this specification in 8.6.2. A big problem that must be addressed and which I've mentioned several times before is that the data types from 8.10 are used in earlier sections of chapter 8 before they are defined here. I can't figure out which order to read this chapter in, as text from 8.10 subtly modifies the interpretation of 8.6.2. Solving this problem by moving this content to or near 8.6.2 would help solve the others as well. Can a Property Descriptor include both [[setter]] and [[value]] fields? 8.10 is ambiguous on that. 9: Decimal support broken in most of the tables. 9.3: ToDecimal on a Number gives the Number unchanged? ToNumber on a Decimal is not defined. 9.8: ToString on a Decimal is not defined in the table. The algorithm only works on Number values. +0, -0, etc. are Number values, not Decimal values. Also, it internally references conversions to Numbers. 9.3.1: ToDecimal on a string results in a Number. Also, it optionally drops significant digits after the 20th. 10.2: "functrions" 10.2.1: "binding can not be set throw a TypeError exception": Missing comma. 10.2.1.1: "a ECMAScrpt": a -> an and fix spelling error "A declarative environment record binding the set of identifiers defined by the declarations contained within its scope.": Not a sentence. 10.2.1.1.x: Be consistent about spaces before the opening parenthesis of formal parameters. 10.2.1.1.6: "The S argument is ignored because stict mode deoes not change the meaning of setting bindings in declarative environment records have .": Ah, that's what "S" is for? You didn't explain this earlier when S was first mentioned in the other methods. Also, fix grammar errors. 10.2.1.2.x: Same comments as above. Also lots of typos in various places. 10.2.1.2.1: This will mean that having bindings in the prototype will prevent one from building ones in the leaf object. 10.2.1.2.4: "of it's associated ": it's -> its "4. If Result(3) is false or the binding for N in Result(1) is an uninitialized immutable binding, then": What's an uninitialized immutable binding here? Result(3) is an object, not an environment. Objects have properties, not bindings. 10.2.1.2.5: This will always error out in DefineOwnProperty. 10.2.1.2.6: "3. If the binding for N in Result(1) is a mutable binding, then": What is a mutable binding? Result(1) is an object, not an environment. "4. Else this must be an attempt to change the value of an immutable binding so throw a TypeError exception.": This doesn't follow. For example, just because Result(1) has no binding doesn't mean that its prototype doesn't. 10.2.2.1: "called with a lexical environment lex, identifier string, name, and boolan flag strict the following steps are performed": Due to several grammar errors (an extra comma and a missing one) this doesn't mean what it's supposed to. 10.2.2.x: "is call" -> "is called". Lots of other typos as well. 10.2.2.4: There is no current lexical environment bound around the declaration of PopEnvironnmentRecord. 10.3: "to tract the execution" What is VariableEnvironment for? It's never used in the spec, except for a mention in 12.2 which is a bug and shouldn't be there. 10.3.2: Can't do the arguments object this way. It's incompatible with ES3 and current practice for multiple arguments sharing the same name. You also don't want users extracting the getters and setters out of the arguments array, etc. Also, the notion of scope in which the getters and setters are eval'd is fuzzy at best and can cause problems if other definitions ever shadow the parameter names. 10.3.3: "Variables and functions declared in ECMAScript code evaluate in the execution context are added as bindings in the that environment record." Huh? "1. Let env be the running execution context's VariableEnvironment." How do those get created? Section 10.4 should come first. 10.4: This is still confusing. What creates execution contexts? There is no such step in the algorithms here. 12.2: This breaks ES3 and existing practice. Consider with(o) {var x = 3} if o.x exists and has the value 7. This code currently sets o.x to 3; the proposed change would leave it at 7. 13: "code code" 14: The syntax of the use strict directive is incompatible with the lexer grammar. There is no such separate token. What happens if someone escapes a character within the use strict directive token? The spaces before "use" and at the end are mandatory? Is it mandatory that the semicolon follow without an intervening space? How does the semicolon interact with semicolon insertion? Strict directives are ambiguous with statements. There should be no "opt" after UseStrictDirective's definition.