On Jan 9, 2012, at 7:54 AM, Brendan Eich wrote: > The question is how bad these will be for anyone writing JS naively, based on > current and emerging (ES6) docs, without explicit opt-in. > > The answer entails at least: > > 1. ES5-strict semantic changes, e.g. arguments aliasing, without early errors.
I should have written more, since "without early errors" is an assumption, not a requirement. Allen's state machine o.p discussed this more. From Allen's o.p.: ES5~EAS6: The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics. For example, accessing a formal parameter after an assignment to the corresponding element of the function's arguments object. This triggers different state transitions. I'm working on SpiderMonkey now, and we already must analyze for arguments[i] and formal parameter assignments to deoptimize nonstrict code. The main challenge is good error blame when the compiler detects a conflict requiring an early error. You want to blame both the (possibly much earlier) formal or arguments[i] assignment, and the later ES6 feature. I believe that all current optimizing JS engines have to do this kind of analysis. So I wonder if it wouldn't be "easy" (not sure how normative we make this) to deal with (1) with early errors. /be
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
