There was two parts to may message, an informal overview of the proposed semantics and the excerpt from the actual "formal" (and I use that term advisedly) specification of the semantics. I was using the term "top-level" in the informal part of the message to refer to code that wasn't in a nested block. It is not intended to be new formal terminology of the specification. It has nothing to do with the [[Scope]] property. I do introduce some new formal terminology but it is all in the specification excerpt, not in the informal overview. [[Scope]] is simply the internal property that is used to capture the lexical environment (the scope chain) that is active when a function object is created.
What I do introduce is a new kind of execution context for lexical blocks and a new kind of activation object that is associated with lexical block execution contexts. You confusion about the meaning of my informal language reasonably points out the weakness of informal descriptions. Please read the actual rewrite of section 10 and see if you also find it confusing or ambiguous. If so, that's important and something I will try to fix. Regarding, the "cautious subset" restrictions. By design, they are incompatible with ES3. The cautious subset (or the similar but not yet identical ES4 strict mode" is an Opt-in subset of the ES3.1 language that among other things allows a programmer to request that certain problematic ES3 constructs become illegal and generate errors. Every valid proposed ES3.1 cautious subset program is also a valid program in the full language. However, every valid program in the full language is not necessarily a valid cautious subset program. -----Original Message----- From: Garrett Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2008 6:48 PM To: Allen Wirfs-Brock Cc: es4-discuss@mozilla.org; Mark S. Miller; Herman Venter; Pratap Lakshman (VJ#SDK); Douglas Crockford Subject: Re: Newly revised Section 10 for ES3.1. 2008/7/9 Allen Wirfs-Brock <[EMAIL PROTECTED]>: > I've just finished reworking section 10 to better accommodate block scoped > function declarations and const statements. In the course of this I had to > make various decisions about the semantics. The primary purpose of this > message is to provide visibility to those decisions and to get feedback on > them. > > > > In introducing const statements and block scoped function declaration I > tried to apply two over-riding principles: > > 1) Anything that is valid to do in ES3 continues to have the exact same > semantics. > > 2) Anything thing that is new (or non-standard) and would not be valid in > ES3 should have a semantics that is rational and consistent with a future > introduction of block scoped Let variable bindings > > A FunctionDeclaration in a block is not valid in ES3, so apparently that is the reason for your note. > > Here are the results: > > All var declarations continue to be hoisted to "top-level" execution > context. Vars never have block level scope or extent. > > ("top-level" mean the global code, eval code, or the top-level of a > function. > This sentence is confusing. eval code is not necessarily global. Reading further down, it seems that you mean to define "top-level" as a new term for what we already know to mean [[Scope]] and then to define a block scope term. It seems that you are aiming to differentiate between function scope and a new type of "block" scope. If my assumption is correct, then creating a new type of "block" scope does not necessitate changing the term [[Scope]] to "top level". [[Scope]] can still be [[Scope]] and block scope can be called whatever you like ([[Block]], [[BlockScope]], et c) Does this sound reasonable? > > > Function declarations and const declarations are processed in parallel > within a lexical contour (top-level or block). Neither has precedence over > the other, unlike the manner in which function declarations take precedence > over formal parameters in ES3. > > > > A "top-level" function declaration over-writes any like-named formal > parameters or preceding like-named function declarations. This is an ES3 > semantics. > The global object cannot have parameters, so I should probably assume that top-level means the same thing as [[Scope]] in ES3. When you use a made-up word like "over-writes" it is unclear. It could mean any of: 1) replaces the value 2) replaces the value and attributes 3) shadows a property in the scope chain (some do use the term "override" in this way) It is not clear what you mean. > "Top-level" function declarations are writable. Subsequent declarations or > assignments may change their value. This is an ES3 semantics. > I'm not sure how you understand it, but let me explain how I understand it, and maybe you'll see why what you've written is confusing to me. A FunctionDeclaration creates a property on the Variable object (or replaces the value and attributes if it it already exists). To quote the relevant part of the spec: | 10.1.3 Variable Instantiation | | Every execution context has associated with it a variable object. | Variables and functions declared in the source text are added as | properties of the variable object. For function code, parameters | are added as properties of the variable object. http://bclary.com/2004/11/07/#a-10.1.3 [snip] > > Within in a block, function declarations are read-only bindings. Since > declarations in blocks are new, this is a new semantics. IOW, a FunctionDeclaration creates a property of the BlockScope with the attributes {ReadOnly, DontDelete} > > In the course of this, I noticed a number of conditions that plausibly might > be restricted in the cautious subset, but currently aren't specified as > such: > > * Illegal for a function to have duplicately named formal parameters > Is this a problem in ES3? > * Illegal for a function to contain a top level function declaration > with a function name that is the same as a formal parameter. > > * Illegal to have multiple top level function declarations for the > same function name > > * Illegal to have a function declaration with the same name as var > declaration. > > * Illegal for a function to contain a var declaration with the same > name as a formal parameter. > > * Illegal to assign to a top-level function name. > Five sensible suggestions, but they would be incompatible with ES3.0 (see quote above). [snip] > 10.1.6.1 Usage Subset cautious Restrictions > > For functions defined within an execution subset restricted to the cautious > subset, the activation object is only initialized with an "arguments" > property if the function mentions "arguments" freely in its body. In which > case the "arguments" property is initialized with attributes {[[Writable]]: > false, [[Enumerable]]: false, [[Flexible]]: false}. > That would be incompatible with ES3. Arguments is not ReadOnly (or "Writable:false"). (Doesn't seem like it would create a problem but this violate your "rule 1") Valid ES3: function z() { arguments = 1; return arguments; } z(); Garrett _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
