LexicalEnvironment and VariableEnvironment in ECMA-262

# Axel Rauschmayer (14 years ago)

FWIW: I’ve written down my understanding of the differences between LexicalEnvironment and VariableEnvironment in ECMA-262:

www.2ality.com/2011/04/ecmascript-5-spec-lexicalenvironment.html

Greetings,

Axel

# Claus Reinke (14 years ago)

FWIW: I've written down my understanding of the differences between LexicalEnvironment and VariableEnvironment in ECMA-262: www.2ality.com/2011/04/ecmascript-5-spec-lexicalenvironment.html

Thanks, another surprising detail. The standard disallows FunctionDeclaration as statement, acknowledges that implementations don't follow suit, and recommends that they should [12, Note].

Perhaps you should have used 'catch' instead of 'with' for your example - the combination of

- implementations allowing FunctionDeclaration as statement
- implementations differ in how such FunctionDeclarations 
    are hoisted
- ES/next limiting FunctionDeclaration hoisting to blocks

seems to imply that for some implementations, ES/next will have different behaviour than ES5+FD-statements, for identical program code (if I am reading this correctly, that is):

function Outer() {
  var e = "Outer";
  try { throw "Inner"; }
  catch (e) {
    function F() { log(e); }   // some implementations hoist 
                               // 'F' without closing over 'e';
    F();                       // those have to change here for ES/next
    (function() { log(e); }());
    log(e);
  }
}
Outer();

My reading: some current implementations bind the 'e' in 'F' to the 'Outer' 'e', while ES/next (and lexical scoping intuition) will require a binding to the exception parameter.

Time for those implementations to change/raise warnings now, before the switch? As is already recommended in the current standard [12, note on page 86]..

I did not expect that. Claus

# Brendan Eich (14 years ago)

On Apr 22, 2011, at 3:34 PM, Claus Reinke wrote:

Perhaps you should have used 'catch' instead of 'with' for your example - the combination of

  • implementations allowing FunctionDeclaration as statement
  • implementations differ in how such FunctionDeclarations are hoisted
  • ES/next limiting FunctionDeclaration hoisting to blocks

seems to imply that for some implementations, ES/next will have different behaviour than ES5+FD-statements,

Yes, that's right, but as stated it might seem to imply that implementations agree with one another on FD-in-block today. Current implementations do not all agree, so migrating will involve work and testing in any event.

For this reason, ES5 strict implemented in Firefox 4 (SpiderMonkey) makes FD-in-block an error:

js> function f() { "use strict"; if (C) { function D(){} } }

typein:2: SyntaxError: in strict mode code, functions may be declared only at top level or immediately within another function: typein:2: function f() { "use strict"; if (C) { function D(){} } } typein:2: ...............................................^

# Mark S. Miller (14 years ago)

On Sat, Apr 23, 2011 at 1:19 PM, Brendan Eich <brendan at mozilla.com> wrote:

On Apr 22, 2011, at 3:34 PM, Claus Reinke wrote:

Perhaps you should have used 'catch' instead of 'with' for your example - the combination of

  • implementations allowing FunctionDeclaration as statement
  • implementations differ in how such FunctionDeclarations are hoisted
  • ES/next limiting FunctionDeclaration hoisting to blocks

seems to imply that for some implementations, ES/next will have different behaviour than ES5+FD-statements,

Yes, that's right, but as stated it might seem to imply that implementations agree with one another on FD-in-block today. Current implementations do not all agree, so migrating will involve work and testing in any event.

For this reason, ES5 strict implemented in Firefox 4 (SpiderMonkey) makes FD-in-block an error:

Also a SyntaxError in Chrome 12.0.742.5 dev and Safari Version 5.0.4 (5533.20.27, r84622).