LR(1) grammar/parser and lookahead-restrictions

Michael Dyck jmdyck at
Fri Feb 3 16:17:20 UTC 2017

On 17-02-02 06:23 PM, Waldemar Horwat wrote:
> Lookahead restrictions fit very well into an LR(1) engine

Again: Great, but how? E.g., do you pre-process the grammar, modify the 
construction of the automaton, and/or modify the operation of the parser?

> as long as they're limited to only one token, and that's what I've
> implemented in the validator.

So when the grammar has a prohibited lookahead-sequence with more than one 
token (in ExpressionStatement, IterationStatement, and ExportDeclaration), 
does the validator just use the first token?

> You need to be very careful with them if looking more than one token
> ahead because lexing of the tokens can vary based on context. For
> example, if the next few characters in front of the cursor are )/abc/i+,
> then what is the second token? What is the third token? It's actually
> context-dependent.

But the context-dependentness of lexing is a parse-time problem, not a 
validation-time problem, right? The syntactic level can just assume a stream 
of (correctly lexed) input elements. Or do you validate deeper than the 
syntactic grammar?

(And it seems to me that multi-token lookahead-restrictions would be hard 
for a validator to handle even if lexing *wasn't* context-dependent, but 
maybe that depends on how you handle them.)


More information about the es-discuss mailing list