Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
LR parser
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
=== Parse table for the example grammar === Most LR parsers are table driven. The parser's program code is a simple generic loop that is the same for all grammars and languages. The knowledge of the grammar and its syntactic implications are encoded into unchanging data tables called '''parse tables''' (or '''parsing tables'''). Entries in a table show whether to shift or reduce (and by which grammar rule), for every legal combination of parser state and lookahead symbol. The parse tables also tell how to compute the next state, given just a current state and a next symbol. The parse tables are much larger than the grammar. LR tables are hard to accurately compute by hand for big grammars. So they are mechanically derived from the grammar by some [[parser generator]] tool like [[GNU Bison|Bison]].<ref>Flex & Bison: Text Processing Tools, by John Levine, O'Reilly Media 2009.</ref> Depending on how the states and parsing table are generated, the resulting parser is called either a [[simple LR parser|'''SLR''' (simple LR) parser]], [[LALR parser|'''LALR''' (look-ahead LR) parser]], or [[canonical LR parser]]. LALR parsers handle more grammars than SLR parsers. Canonical LR parsers handle even more grammars, but use many more states and much larger tables. The example grammar is SLR. LR parse tables are two-dimensional. Each current LR(0) parser state has its own row. Each possible next symbol has its own column. Some combinations of state and next symbol are not possible for valid input streams. These blank cells trigger syntax error messages. The '''Action''' left half of the table has columns for lookahead terminal symbols. These cells determine whether the next parser action is shift (to state ''n''), or reduce (by grammar rule '''r'''<sub>''n''</sub>). The '''Goto''' right half of the table has columns for nonterminal symbols. These cells show which state to advance to, after some reduction's Left Hand Side has created an expected new instance of that symbol. This is like a shift action but for nonterminals; the lookahead terminal symbol is unchanged. The table column "Current Rules" documents the meaning and syntax possibilities for each state, as worked out by the parser generator. It is not included in the actual tables used at parsing time. The <big>{{color|#f7f|β’}}</big> (pink dot) marker shows where the parser is now, within some partially recognized grammar rules. The things to the left of <big>{{color|#f7f|β’}}</big> have been parsed, and the things to the right are expected soon. A state has several such current rules if the parser has not yet narrowed possibilities down to a single rule. {| class="wikitable" |- ! Curr !! !! colspan="5" | Lookahead !! !! colspan="3" | LHS Goto |- ! State !! Current Rules !! ''int'' !! ''id'' !! * !! + !! ''eof'' !! !! Sums !! Products !! Value |- | 0 || Goal β <big>{{color|#f7f|β’}}</big> Sums ''eof'' || 8 || 9 || || || |||| 1 || 4 || 7 |- | 1 || Goal β Sums <big>{{color|#f7f|β’}}</big> ''eof'' {{br}} Sums β Sums <big>{{color|#f7f|β’}}</big> + Products || || || || {{br}}2 || accept{{br}} |||| || || |- | 2 || Sums β Sums + <big>{{color|#f7f|β’}}</big> Products || 8 || 9 || || || |||| || 3 || 7 |- | 3 || Sums β Sums + Products <big>{{color|#f7f|β’}}</big> {{br}} Products β Products <big>{{color|#f7f|β’}}</big> * Value || || || {{br}}5 || r1 {{br}} || r1 {{br}} |||| || || |- | 4 || Sums β Products <big>{{color|#f7f|β’}}</big> {{br}} Products β Products <big>{{color|#f7f|β’}}</big> * Value || || || {{br}}5 || r2 {{br}} || r2 {{br}} |||| || || |- | 5 || Products β Products * <big>{{color|#f7f|β’}}</big> Value || 8 || 9 || || || |||| || || 6 |- | 6 || Products β Products * Value <big>{{color|#f7f|β’}}</big> || || || r3 || r3 || r3 |||| || || |- | 7 || Products β Value <big>{{color|#f7f|β’}}</big> || || || r4 || r4 || r4 |||| || || |- | 8 || Value β ''int'' <big>{{color|#f7f|β’}}</big> || || || r5 || r5 || r5 |||| || || |- | 9 || Value β ''id'' <big>{{color|#f7f|β’}}</big> || || || r6 || r6 || r6 |||| || || |- |} In state 2 above, the parser has just found and shifted-in the '''+''' of grammar rule ::r1: Sums β Sums + <big>{{color|#f7f|β’}}</big> Products The next expected phrase is Products. Products begins with terminal symbols ''int'' or ''id''. If the lookahead is either of those, the parser shifts them in and advances to state 8 or 9, respectively. When a Products has been found, the parser advances to state 3 to accumulate the complete list of summands and find the end of rule r0. A Products can also begin with nonterminal Value. For any other lookahead or nonterminal, the parser announces a syntax error. {{rule}} In state 3, the parser has just found a Products phrase, that could be from two possible grammar rules: ::r1: Sums β Sums + Products <big>{{color|#f7f|β’}}</big> ::r3: Products β Products <big>{{color|#f7f|β’}}</big> * Value The choice between r1 and r3 can't be decided just from looking backwards at prior phrases. The parser has to check the lookahead symbol to tell what to do. If the lookahead is '''*''', it is in rule 3, so the parser shifts in the '''*''' and advances to state 5. If the lookahead is ''eof'', it is at the end of rule 1 and rule 0, so the parser is done. {{rule}} In state 9 above, all the non-blank, non-error cells are for the same reduction r6. Some parsers save time and table space by not checking the lookahead symbol in these simple cases. Syntax errors are then detected somewhat later, after some harmless reductions, but still before the next shift action or parser decision. Individual table cells must not hold multiple, alternative actions, otherwise the parser would be nondeterministic with guesswork and backtracking. If the grammar is not LR(1), some cells will have shift/reduce conflicts between a possible shift action and reduce action, or reduce/reduce conflicts between multiple grammar rules. LR(''k'') parsers resolve these conflicts (where possible) by checking additional lookahead symbols beyond the first.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)