Newly revised Section 10 for ES3.1.

[Garrett Smith]

2008/7/9 Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com>:
> 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