Clarification needed on 10.2.1.1.3 SetMutableBinding on a Declarative Environment Record
On Sat, Jun 5, 2010 at 9:41 PM, Mark S. Miller <erights at google.com> wrote:
On SpiderMonkey, WebKit, and V8 and, I see
Opera too.
On Jun 5, 2010, at 9:41 PM, Mark S. Miller wrote:
Am I misunderstanding something, or 2) was this the intended spec,
or 3) are these three browsers all non-conformant in the same
manner? If the 3rd, I'll file bugs on this. If the 2nd, should we
add a correction to the ES5 errata?
Whatever happened to "don't break the web"? :-P
The ES3 spec has no exception here. If ES5 introduced an incompatible
change, we should issue an erratum.
On Sat, Jun 5, 2010 at 10:01 PM, Brendan Eich <brendan at mozilla.com> wrote:
On Jun 5, 2010, at 9:41 PM, Mark S. Miller wrote:
Am I misunderstanding something, or 2) was this the intended spec, or 3) are these three browsers all non-conformant in the same manner? If the 3rd, I'll file bugs on this. If the 2nd, should we add a correction to the ES5 errata?
Whatever happened to "don't break the web"? :-P
The ES3 spec has no exception here. If ES5 introduced an incompatible change, we should issue an erratum.
+1. I suggest replacing the text I quote above with
If the binding is an immutable binding and S is true, then a TypeError is thrown.
And algorithmic step 4:
- Else this must be an attempt to change the value of an immutable binding so throw a TypeError exception.
should be changed to
- Else this must be an attempt to change the value of an immutable binding, so
a. If S is true, throw a TypeError exception.
The text for SetMutableBinding in table 17 is correct:
[...] If S is true and the binding cannot be set throw a TypeError exception. S is used to identify strict mode references.
supporting the notion that the text in 10.2.1.1.3 is an errata.
Agreed. I will correct it in the errata
From: es5-discuss-bounces at mozilla.org [mailto:es5-discuss-bounces at mozilla.org] On Behalf Of Mark S. Miller Sent: Saturday, June 05, 2010 11:03 PM To: Brendan Eich Cc: es-discuss; es5-discuss at mozilla.org Subject: Re: Clarification needed on 10.2.1.1.3 SetMutableBinding on a Declarative Environment Record
On Sat, Jun 5, 2010 at 11:02 PM, Mark S. Miller <erights at google.com<mailto:erights at google.com>> wrote:
The text for SetMutableBinding in table 17 is correct:
[...] If S is true and the binding cannot be set throw a TypeError exception. S is used to identify strict mode references.
supporting the notion that the text in 10.2.1.1.3 is an errata.
Or rather, is a mistake to be fixed in an errata ;).
On Sat, Jun 5, 2010 at 10:27 PM, Mark S. Miller <erights at google.com<mailto:erights at google.com>> wrote:
On Sat, Jun 5, 2010 at 10:01 PM, Brendan Eich <brendan at mozilla.com<mailto:brendan at mozilla.com>> wrote:
On Jun 5, 2010, at 9:41 PM, Mark S. Miller wrote:
Am I misunderstanding something, or 2) was this the intended spec, or 3) are these three browsers all non-conformant in the same manner? If the 3rd, I'll file bugs on this. If the 2nd, should we add a correction to the ES5 errata?
Whatever happened to "don't break the web"? :-P
The ES3 spec has no exception here. If ES5 introduced an incompatible change, we should issue an erratum.
+1. I suggest replacing the text I quote above with
If the binding is an immutable binding and S is true, then a TypeError is thrown.
And algorithmic step 4:
- Else this must be an attempt to change the value of an immutable binding so throw a TypeError exception.
should be changed to
- Else this must be an attempt to change the value of an immutable binding, so a. If S is true, throw a TypeError exception.
On SpiderMonkey, WebKit, and V8 and, I see
var bar = function foo(f) { if (f) {foo = f; foo();} else {print(33);} }; bar(function(){print(44);}); 33
which is the behavior I would normally have expected for non-strict code. The reason the assignment to foo correctly doesn't take is that a named FunctionExpression brings its name into scope with CreateImmutableBinding and InitializeImmutableBinding (See the 2nd FunctionExpression production semantics at the top of chapter 13). For strict mode code I would expect the failed assignment to fail with a thrown error, but I would normally not have been surprised by the silent error for non-strict code. That is, until rereading the following text from 10.2.1.1.3 SetMutableBinding(N,V,S):
[...] If the binding is an immutable binding, a TypeError is always thrown. The S argument is ignored because strict mode does not change the meaning of setting bindings in declarative environment records.
Am I misunderstanding something, or 2) was this the intended spec, or 3) are these three browsers all non-conformant in the same manner? If the 3rd, I'll file bugs on this. If the 2nd, should we add a correction to the ES5 errata?
On SpiderMonkey, WebKit, and V8 and, I see var bar = function foo(f) { if (f) {foo = f; foo();} else {print(33);} }; bar(function(){print(44);}); 33 which is the behavior I would normally have expected for non-strict code. The reason the assignment to foo correctly doesn't take is that a named FunctionExpression brings its name into scope with CreateImmutableBinding and InitializeImmutableBinding (See the 2nd FunctionExpression production semantics at the top of chapter 13). For strict mode code I would expect the failed assignment to fail with a thrown error, but I would normally not have been surprised by the silent error for non-strict code. That is, until rereading the following text from 10.2.1.1.3 SetMutableBinding(N,V,S): [...] If the binding is an immutable binding, a TypeError is always thrown. The S argument is ignored because strict mode does not change the meaning of setting bindings in declarative environment records. Am I misunderstanding something, or 2) was this the intended spec, or 3) are these three browsers all non-conformant in the same manner? If the 3rd, I'll file bugs on this. If the 2nd, should we add a correction to the ES5 errata? -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100605/8318590e/attachment-0001.html>