Directive prologue members, escapes, and retroactive syntax errors

Peter van der Zee ecma at
Fri Oct 15 01:10:48 PDT 2010

I see your point. I don't know how SpiderMonkey exactly parses it, but it
seems as much an edge case as RegularExpressionLiteral vs DivPunctuator. Eg.
the parser should tell the lexer what it expects, div or regex.

The same applies here. The parser can simply tell the lexer whether it wants
a token in strict mode or not. In that case the parser, which should know
it's parsing a DirectivePrologue, could just turn off the strict flag in the
request. Does that make sense? Or is that useless for parsers that take a
different approach...?

Because the parser can clearly tell the difference between parsing
a DirectivePrologue and a StringLiteral. So it can be told that whenever
it's parsing a DirectivePrologue the strict flag should be considered to be
false. Cases like `"a"+b` don't really apply for me (since they're simply
not a DirectivePrologue), but I don't know how other parsers would handle

- peter

On Thu, Oct 14, 2010 at 2:46 PM, Jeff Walden
<jwalden+es at<jwalden%2Bes at>
> wrote:

> On 10/14/2010 12:40 AM, Peter van der Zee wrote:
>> Can't we just say directive prologues are unaffected by strict mode
>> altogether? They have unobservable side-effects (they're strings, it's what
>> they do). That would prevent backtracking. But I agree that at least some
>> clear cut decision should be made regarding the directives in strict mode.
>> So basically what I propose is that as long as you are still parsing
>> directive prologues, strict mode does not apply and no errors are thrown
>> because of it. The active check for strict mode strictness could then be
>> activated on the first token that's not a string.
> SpiderMonkey detects, and rejects, octal string syntax within the
> tokenizer.  This seems like the right place to me.  Ignoring strict mode in
> the directive prologue would mean you'd have to move octal-string rejection
> out of the tokenizer.  But you can't remove it completely, because then you
> run into the limited-rollback problem.  So as far as I can tell your idea
> would require saving a flag to record strings containing octal escapes, then
> only checking that if not in the directive prologue -- but you don't even
> know if you're in the directive prologue if you've just parsed a string this
> way!  Consider:
> function foo()
> {
>  "use strict";
>  "\145"
>  + "0" + 5;
> }
> You don't know if "\145" is part of the DP (and thus whether the escape
> should be ignored) until a bit after the string.  At that point it seems
> like you need a post-DP check to permit the escape, and you need to store
> *yet more* state to indicate you're definitely parsing after the DP.  This
> seems possibly even more problematic to me than the retroactive syntax error
> which triggered this entire discussion, but maybe I'm missing some clever
> technique to keep it simple.
> Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es5-discuss mailing list