Directive prologue members, escapes, and retroactive syntax errors

Peter van der Zee ecma at qfox.nl
Sat Oct 16 12:36:20 PDT 2010


> On Oct 16, 2010, at 2:33 AM, Peter van der Zee wrote:
>
>> Brendan: well for my own parser the lookhead is kind of "free"
>> (or inherent because it always does an exhaustive tree search).
>> In the production I gave earlier, the lookahead cost would be at
>> most one StringLiteral, since as soon as the next character after
>> that string is not a semi-colon or newline, you know you're no
>> longer parsing a directive.
>>
>
> Yes, that's fine -- parsing directives is not the issue. The
> question is when do you detect an octal escape in an already-lexed
> directive and, because of a later "use strict"; call it an error?
> Do you have to re-scan for octal escapes, or remember whether you
> scanned any in a preceding directive?

You don't.

Whether a Directive Prologue does or does not contain an escape does not, in any
case, change the behavior of the Program. The only question is whether or not an
error should be thrown due to strict mode. My suggestion was to ignore any
strict mode rules while parsing string-literal "statements" (not part of a more
complex expression) at the start of a Program.

Whether a directive contains an (octal) escape or not should not matter. Octals
were an implementors extension as per appendix B. If an implementor supports
them, then it should (probably) support them as a directive. Otherwise, it
can't. The result will not matter because the string literal does not affect
anything.

So by not throwing any kind of strict mode error for directives, you don't have
to worry about it either. You have the worst case penalty of one string literal
to re-parse. The tokenizer can be instructed by whoever governs it, just like it
does with regex vs div.

- peter


More information about the es5-discuss mailing list