Where to Report Spec Errata?
On Sun, May 9, 2010 at 3:50 PM, Erik Arvidsson <erik.arvidsson at gmail.com>wrote:
On Sun, May 9, 2010 at 15:19, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
Where is the right place to report errata in the ES5 specification?
This mailing list.
For ES5 errata, please send to es5-discuss as well.
On Sun, May 9, 2010 at 3:56 PM, Mark S. Miller <erights at google.com> wrote:
On Sun, May 9, 2010 at 3:50 PM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
On Sun, May 9, 2010 at 15:19, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
Where is the right place to report errata in the ES5 specification?
This mailing list.
For ES5 errata, please send to es5-discuss as well.
OK.
A formal bugtracker has some advantages, too. Can organize, prioritize bugs and feature requests, add comments, testcases.
Buglist: Function.prototype.toString -> s/FunctionDeclaration/FunctionExpression. Error instances have a message property, but it is not specified (as mentioned previously) RegularExpressionLiteral is missing from Annex A.1 Lexical Grammar
Wishlist: A bugtracker (just one) for Harmony and ES5 Error stack, either instance property or as a getter on Error.prototype Top level Array Generics
Other interesting proposals: Regex feature requests from Steve Levithan's Regex pages blog.stevenlevithan.com/archives/fixing
Function.prototype.toString -> s/FunctionDeclaration/FunctionExpression.
This is not an error. FunctionDeclaration is intentional and is traceable back to the ES1 spec. There was discussion on this topic on es-discuss but there was no clear consensus on making this specific change or any of the alternatives that were discussed.
Error instances have a message property, but it is not specified (as mentioned previously)
This is not an error, the 'message' property is defined in 15.11.4.3 as a property of Error.prototype (which all defined error instances inherit from) and 15.11.1.1 and 15.11.2.1 makes it clear that the message value specified when creating an error object is used to set the own 'message' property of the new object (and hence over-rides the inherited 'message' property. Arguably, it would be more consistent with the organization of the rest of Chapter 15 if 'message' and 'name' were defined in 15.11.5 but that would not change any actual requirements defined by the specification. This is neither a technical issue nor a actual editorial 'bug' (such as a misspelling) so it really doesn't belong in the ES5 errata. (The purposwe of the errata is to list actual unintended bugs in the document, not to serve as the first working draft of the next edition).
RegularExpressionLiteral is missing from Annex A.1 Lexical Grammar
Ok, got it.
On Mon, May 10, 2010 at 11:18 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:
Function.prototype.toString -> s/FunctionDeclaration/FunctionExpression.
This is not an error. FunctionDeclaration is intentional and is traceable back to the ES1 spec. There was discussion on this topic on es-discuss but there was no clear consensus on making this specific change or any of the alternatives that were discussed.
It was discussed and the specification states that a representation of a FunctionDeclaration is returned. This is not an editorial bug, but a specification of behavior that implementations violate, with reason, and will continue to violate in the case of anonymous functions:
var fString = (function(){}).toString();
None of the major implementations return a FunctionDeclaration representation. Are all implementations wrong or is the spec wrong?
I don't want to go on like a broken record, reiterating the same arguments. It seems this issue could go on a bug tracker where it could either be accepted or marked INVALID.
Error instances have a message property, but it is not specified (as mentioned previously)
This is not an error, the 'message' property is defined in 15.11.4.3 as a property of Error.prototype (which all defined error instances inherit from) and 15.11.1.1 and 15.11.2.1 makes it clear that the message value specified when creating an error object is used to set the own 'message' property of the new object (and hence over-rides the inherited 'message' property. Arguably, it would be more consistent with the organization of the rest of Chapter 15 if 'message' and 'name' were defined in 15.11.5 but that would not change any actual requirements defined by the specification. This is neither a technical issue nor a actual editorial 'bug' (such as a misspelling) so it really doesn't belong in the ES5 errata. (The purposwe of the errata is to list actual unintended bugs in the document, not to serve as the first working draft of the next edition).
Error instance properties: I see where Error message instance is set when the Error constructor is called.
I also agree that it would be clearer to have message and name
mentioned in 15.11.5 compared to what is there now:
| 15.11.5 Error instances have no special properties.
Sounds like there is an Errata document in the works. Will that be published on ecma-international.org?
I was not proposing the RegExp or top level Array generics go in an Errata document -- that's not what was meant. They are interesting and useful proposals, though, along with catchalls proposal.
Regardless of what implementations actually do, the standard is the standard until it is changed.
The reason it wasn't changed was because simply changing FunctionDeclaration or FunctionExpression wasn't enough to adequately specify the behavior. Even if existing implementations handled all the edge cases identically (and it isn't clear that they do), it still takes consider work to research it, write a complete specification and get consensus on it. There wasn't time in the ES5 schedule to do it, so rather than putting in a incomplete/inadequate fix we just left it was in all previous editions. Hopefully, that preserves the pressure to really fix it correctly in the next editions.
The errata can be accessed from the start page of wiki.ecmascript.org and we'll get a link setup from the ecmascript.org.
Do keep bugs and suggestions coming. I can worry about sorting into ES5 errata vs. work items for Harmony
Where is the right place to report errata in the ES5 specification?