January 19 meeting notes

Andreas Rossberg rossberg at google.com
Fri Jan 20 10:17:51 PST 2012

On 20 January 2012 18:26, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> On 20 January 2012 01:40, Waldemar Horwat<waldemar at google.com>  wrote:
>>> Also, "function (e) {let e;}" should always be an error.
>> Is there a good reason to do this? It would be an unnecessary
>> irregularity with block scoping, and seems like overly nanny-ish (in
>> stark contrast to other parts of the language).
> In general, the binding rules for function parameters were decided at the
> Nov. 2011 meeting (see Nov 16 meeting notes):
> MarkM: Two-scope model (one scope for parameters, an independent inner scope
> for let, const, and var bindings).  This model is upwards-compatible with
> ES5.1 strict because the latter disallows shadowing of a parameter by a
> binding in function scope.
> Allen: Two-scope model, but with inner scope prohibited from shadowing
> parameters.
> MarkM: Likes this.  Any program that is accepted works with either of the
> two-scope model intuitions.
> Whether you view this has two scopes with static semantic rules that
> prohibit inner declarations from shadowing or a single scope with
> appropriate static semantic rules that prevent redeclaration of  formals,
> the effect is essentially the same.  The current specification draft
> actually uses a single environment record and appropriate static semantic
> rules. However you model it in terms of scopes, the intent is that the
> function formal parameters and the top level declarations are treated as a
> single naming contour for the purposes of allowing or disallowing duplicate
> declarations.

Here is a simple model: a function expression introduces one local
scope(*), which contains the parameters and the var variables hoisted
from its body (as in ES5). The function is evaluated by evaluating its
body _as a block_ (which it is, syntactically).

This is a simpler, more compositional rule with fewer special cases.
In effect, you have two scopes, but there is nothing special at all
about the inner one. In particular, var-bound vars are hoisted out of
this block like they are hoisted out of inner blocks.

This is fully backwards compatible, AFAICS.

(*) Ignoring the extra scope for the optional function name.


More information about the es-discuss mailing list