Turning grammar specifications into parsers
A developer can implement a parser directly or describe productions for a generator. The tool computes predictive information or state transitions for its selected method and emits tables or code used during parsing.
Cornell’s notes illustrate LL predictive tables and LR action/goto tables, identifying yacc, Bison, and CUP as generators using LR-related techniques. Supported grammar classes depend on the tool and configuration rather than the label alone.
Recognition and result construction differ
Completing a production can trigger an action such as constructing an AST node from its children. Token values, names, and locations must be conveyed through the chosen interfaces.
Generated recognition does not automatically resolve every identifier, validate types, or determine intended business effects. Semantic checking and code generation retain separate responsibilities beyond matching grammatical structure.
Generated code still needs semantic review
A state admitting competing actions can produce a conflict report. Its cause can be ambiguity or insufficient distinctions in the selected parsing method, not proof that the language cannot be specified.
Precedence and associativity can rule out unwanted parses but can also hide a mistaken choice. Validation should inspect representative structures and failures rather than merely confirm that generated code compiles.