LR(1) grammar/parser and lookahead-restrictions
jmdyck at ibiblio.org
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
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
(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