domenic at domenicdenicola.com (2014-10-15T18:41:24.483Z)
On Wed, Oct 1, 2014 at 8:20 AM, Oliver Hunt <oliver at apple.com> wrote: > 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. First, I agree with you. This shouldn't be a problem. However, both JSC and v8 cause confusion when they use the term "lazy parsing". There are plenty of static errors that could not be reported with a truly lazy parser, i.e., one which actually postpones parsing. v8 for example uses a lightweight but accurate parser that is supposed to catch early errors early, but, afaik, doesn't construct an actual ast. See - https://code.google.com/p/v8/issues/detail?id=2728 - https://code.google.com/p/v8/issues/detail?id=2470 - https://code.google.com/p/google-caja/issues/detail?id=1616 - https://bugs.webkit.org/show_bug.cgi?id=106160 (Oliver, I note that the last bug above is still open, which continues to cause SES to use an expensive workaround when run on Safari.) So the question is not "Can this early error be reported accurately without parsing?", since essentially none can, so no engines postpone parsing. The question is whether a particular new early error would require these lightweight early parsers to do something that they can't do while preserving their current efficiency. Statically apparent assignment to const variables does not seem like a burden. If there is an intervening "with" or sloppy direct eval, then there is not a statically apparent assignment to a const variable. Since this can only occur in sloppy code anyway, it seems more consistent with the rest of sloppy mode for this failed assignment to be silent, rather than dynamically throwing an error.
On Wed, Oct 1, 2014 at 8:20 AM, Oliver Hunt <oliver at apple.com> wrote: > 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. > Hi Oliver, First, I agree with you. This shouldn't be a problem. However, both JSC and v8 cause confusion when they use the term "lazy parsing". There are plenty of static errors that could not be reported with a truly lazy parser, i.e., one which actually postpones parsing. v8 for example uses a lightweight but accurate parser that is supposed to catch early errors early, but, afaik, doesn't construct an actual ast. See https://code.google.com/p/v8/issues/detail?id=2728 https://code.google.com/p/v8/issues/detail?id=2470 https://code.google.com/p/google-caja/issues/detail?id=1616 https://bugs.webkit.org/show_bug.cgi?id=106160 (Oliver, I note that the last bug above is still open, which continues to cause SES to use an expensive workaround when run on Safari.) So the question is not "Can this early error be reported accurately without parsing?", since essentially none can, so no engines postpone parsing. The question is whether a particular new early error would require these lightweight early parsers to do something that they can't do while preserving their current efficiency. Statically apparent assignment to const variables does not seem like a burden. If there is an intervening "with" or sloppy direct eval, then there is not a statically apparent assignment to a const variable. Since this can only occur in sloppy code anyway, it seems more consistent with the rest of sloppy mode for this failed assignment to be silent, rather than dynamically throwing an error. > > —Oliver > > > On Oct 1, 2014, at 7:09 AM, Erik Arvidsson <erik.arvidsson at gmail.com> > 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 <allen at wirfs-brock.com> > 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 >> 2) Statically throwing a Syntax Error in assignment expressions, >> 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 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 >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > erik > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141001/ee5370cd/attachment-0001.html>