Manual

Chapter 8: Debugging Your Parser 91
Bison then proceeds onto the automaton itself, describing each state with it set of items,
also known as pointed rules. Each item is a production rule together with a point (marked
by ‘.’) that the input cursor.
state 0
$accept -> . exp $ (rule 0)
NUM shift, and go to state 1
exp go to state 2
This reads as follows: “state 0 corresponds to being at the very beginning of the parsing,
in the initial rule, right before the start symbol (here, exp). When the parser returns to
this state right after having reduced a rule that produced an exp, the control flow jumps
to state 2. If there is no such transition on a nonterminal symbol, and the look-ahead is
a NUM, then this token is shifted on the parse stack, and the control flow jumps to state 1.
Any other look-ahead triggers a syntax error.”
Even though the only active rule in state 0 seems to be rule 0, the report lists NUM as
a look-ahead token because NUM can be at the beginning of any rule deriving an exp. By
default Bison reports the so-called core or kernel of the item set, but if you want to see
more detail you can invoke bison with ‘--report=itemset’ to list all the items, include
those that can be derived:
state 0
In the state 1...
state 1
$accept -> . exp $ (rule 0)
exp -> . exp ’+’ exp (rule 1)
exp -> . exp ’-’ exp (rule 2)
exp -> . exp ’*’ exp (rule 3)
exp -> . exp ’/’ exp (rule 4)
exp -> . NUM (rule 5)
NUM shift, and go to state 1
exp go to state 2
exp -> NUM . (rule 5)
$default
reduce using rule 5 (exp)
the rule 5, ‘exp: NUM;’, is completed. Whatever the look-ahead token (‘$default’), the
parser will reduce it. If it was coming from state 0, then, after this reduction it will return
to state 0, and will jump to state 2 (‘exp: go to state 2’).
state 2
$accept -> exp . $ (rule 0)