On Jan 31, 2012, at 11:20 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: > ... >> If eval was scoped exactly like a block, then this would fail because each >> function declarations would be block scoped to a new block scope that was >> inaccessible at the actual call site. To get the necessary compatible >> behavior we have to hoist the function out of the block scope created for >> the eval all the way up to the body scope (the Variable Environment) of the >> function, just like var. > > You're right, and this is what the SpiderMonkey function-in-substatement > provided (limited conditional compilation without eval). Crazy as people say, > and we want to remove it. Is it unthinkable to break compatibility for the > eval expansion?
I think there are two differences between the eval case and the function declaration case: 1) there is a standardize and generally correctly implemented semantics for function in eval. Hence it is more likely to be used. 2) people whose are writing code to dynamically construct the source code of a function that will be created via eval are probably think about different issues than. I hypothesize that they are more likely to place the eval in a block that conditionalized by a if statement. Either or both of these may make it more likely that such eval code actually exists. > >> This is will be an additional, scoping variation for function declarations >> that only comes into play for non-strict evals. > > If we have to keep compatibility, then we have 'function' requiring a special > case compared to 'let' with your option 2. Or we take option 1 and have all > the forms, new (let and const) and old (var and function) pollute non-strict > direct eval's dynamic scope. Gah. Exactly, compatibility via option 2 requires treating function like var instead of like let. > > /be >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
