JSC does lazy parsing of nested functions and we have no problem reporting static errors, so i’m not sure what you believe is the problem here.
—Oliver > On Oct 1, 2014, at 7:09 AM, Erik Arvidsson <[email protected]> wrote: > > The static error is problematic. I'm pretty sure that engines that do lazy > parsing of functions is not going to report static errors before doing a full > parse of the function. > > I think we need to either enforce this or remove this restriction. Anything > in between will lead to inconsistent behavior between engines. > > On Tue, Sep 30, 2014 at 8:58 PM, Allen Wirfs-Brock <[email protected] > <mailto:[email protected]>> wrote: > > On Sep 30, 2014, at 5:09 PM, Shu-yu Guo wrote: > >> Hi all, >> >> In the current draft, I see 2 different places where assigning to an >> immutable binding ('const') throws an error: >> >> 1) Dynamically throwing a TypeError in SetMutableBinding, >> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-declarative-environment-records-setmutablebinding-n-v-s >> >> <http://people.mozilla.org/~jorendorff/es6-draft.html#sec-declarative-environment-records-setmutablebinding-n-v-s> >> 2) Statically throwing a Syntax Error in assignment expressions, >> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-assignment-operators-static-semantics-early-errors >> >> <http://people.mozilla.org/~jorendorff/es6-draft.html#sec-assignment-operators-static-semantics-early-errors> > see bug https://bugs.ecmascript.org/show_bug.cgi?id=3148 > <https://bugs.ecmascript.org/show_bug.cgi?id=3148> the "can" in that sentence > isn't meant to be interpreted as "best effort" but instead more along the > lines of "it is provable". > > We need to refine that language, but the test is approximately that there are > no with blocks inside the scope of the const declaration and surrounding the > reference to the const. binding > >> >> 1) throws only in strict mode code, while 2) throws regardless. 2) is also >> best effort; seems to be implementation-dependent what "can statically >> determine" entails. >> >> Is the intention that assigning to consts silently nops if the >> implementation cannot determine the assignment to be to a const statically, >> in non-strict code, but implementations *should* make a best effort to >> report such cases eagerly, regardless of strictness? Seems kind of odd to >> me; perhaps I am misreading? > > 1) looks like a bug to me. I pretty sure it was never the intent for > assignments to const binding to silently fail in non-strict code. The current > semantics of SetMutableBinding is a carry over from ES5 where immutable > bindings were only used (I have to double check this) for FunctionExpression > function name bindings. The legacy of ES3 (hence non-strict ES5) was to did > not throw on assignments to such function name bindings. > > I'll probably have to do some extra special casing to preserve the ES3/5 > semantics for assignment to function names and make the throw unconditional > to other immutable bindings > > Allen > > > > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > > > > > -- > erik > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
