File: bison_8.html

package info (click to toggle)
bisonc%2B%2B 6.09.02-1
links: PTS, VCS
area: main
in suites: forky, sid
size: 5,984 kB
sloc: cpp: 9,375; ansic: 1,505; fortran: 1,134; makefile: 1,062; sh: 526; yacc: 84; lex: 60
file content (982 lines) | stat: -rw-r--r-- 44,012 bytes
parent folder | download | duplicates (11)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
                      "http://www.w3.org/TR/html40/loose.dtd">
<HTML>
<!-- Created on January, 28 2005 by texi2html 1.66 -->
<!--
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
            Karl Berry  <karl@freefriends.org>
            Olaf Bachmann <obachman@mathematik.uni-kl.de>
            and many others.
Maintained by: Many creative people <dev@texi2html.cvshome.org>
Send bugs and suggestions to <users@texi2html.cvshome.org>

-->
<HEAD>
<TITLE>Bison 2.21.5: Algorithm</TITLE>

<META NAME="description" CONTENT="Bison 2.21.5: Algorithm">
<META NAME="keywords" CONTENT="Bison 2.21.5: Algorithm">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META NAME="Generator" CONTENT="texi2html 1.66">

</HEAD>

<BODY LANG="en" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">

<A NAME="SEC67"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_7.html#SEC66"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC68"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_7.html#SEC58"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H1> 5. The Bison Parser Algorithm </H1>
<!--docid::SEC67::-->
<P>

As Bison reads tokens, it pushes them onto a stack along with their
semantic values.  The stack is called the <EM>parser stack</EM>.  Pushing a
token is traditionally called <EM>shifting</EM>.
</P>
<P>

For example, suppose the infix calculator has read `<SAMP>1 + 5 *</SAMP>', with a
`<SAMP>3</SAMP>' to come.  The stack will have four elements, one for each token
that was shifted.
</P>
<P>

But the stack does not always have an element for each token read.  When
the last <VAR>n</VAR> tokens and groupings shifted match the components of a
grammar rule, they can be combined according to that rule.  This is called
<EM>reduction</EM>.  Those tokens and groupings are replaced on the stack by a
single grouping whose symbol is the result (left hand side) of that rule.
Running the rule's action is part of the process of reduction, because this
is what computes the semantic value of the resulting grouping.
</P>
<P>

For example, if the infix calculator's parser stack contains this:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>1 + 5 * 3
</pre></td></tr></table><P>

and the next input token is a newline character, then the last three
elements can be reduced to 15 via the rule:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>expr: expr '*' expr;
</pre></td></tr></table><P>

Then the stack contains just these three elements:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>1 + 15
</pre></td></tr></table><P>

At this point, another reduction can be made, resulting in the single value
16.  Then the newline token can be shifted.
</P>
<P>

The parser tries, by shifts and reductions, to reduce the entire input down
to a single grouping whose symbol is the grammar's start-symbol
(see section <A HREF="bison_4.html#SEC7">Languages and Context-Free Grammars</A>).
</P>
<P>

This kind of parser is known in the literature as a bottom-up parser.
</P>
<P>

<TABLE BORDER="0" CELLSPACING="0">
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="bison_8.html#SEC68">5.1 Look-Ahead Tokens</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">Parser looks one token ahead when deciding what to do.</TD></TR>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="bison_8.html#SEC69">5.2 Shift/Reduce Conflicts</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">Conflicts: when either shifting or reduction is valid.</TD></TR>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="bison_8.html#SEC70">5.3 Operator Precedence</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">Operator precedence works by resolving conflicts.</TD></TR>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="bison_8.html#SEC75">5.4 Context-Dependent Precedence</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">When an operator's precedence depends on context.</TD></TR>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="bison_8.html#SEC76">5.5 Parser States</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">The parser is a finite-state-machine with stack.</TD></TR>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="bison_8.html#SEC77">5.6 Reduce/Reduce Conflicts</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">When two rules are applicable in the same situation.</TD></TR>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="bison_8.html#SEC78">5.7 Mysterious Reduce/Reduce Conflicts</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">Reduce/reduce conflicts that look unjustified.</TD></TR>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="bison_8.html#SEC79">5.8 Stack Overflow, and How to Avoid It</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">What happens when stack gets full.  How to avoid it.</TD></TR>
</TABLE>
<P>

<A NAME="Look-Ahead"></A>
<HR SIZE="6">
<A NAME="SEC68"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC69"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H2> 5.1 Look-Ahead Tokens </H2>
<!--docid::SEC68::-->
<P>

The Bison parser does <EM>not</EM> always reduce immediately as soon as the
last <VAR>n</VAR> tokens and groupings match a rule.  This is because such a
simple strategy is inadequate to handle most languages.  Instead, when a
reduction is possible, the parser sometimes &quot;looks ahead&quot; at the next
token in order to decide what to do.
</P>
<P>

When a token is read, it is not immediately shifted; first it becomes the
<EM>look-ahead token</EM>, which is not on the stack.  Now the parser can
perform one or more reductions of tokens and groupings on the stack, while
the look-ahead token remains off to the side.  When no more reductions
should take place, the look-ahead token is shifted onto the stack.  This
does not mean that all possible reductions have been done; depending on the
token type of the look-ahead token, some rules may choose to delay their
application.
</P>
<P>

Here is a simple case where look-ahead is needed.  These three rules define
expressions which contain binary addition operators and postfix unary
factorial operators (`<SAMP>!</SAMP>'), and allow parentheses for grouping.
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>expr:     term '+' expr
        | term
        ;

term:     '(' expr ')'
        | term '!'
        | NUMBER
        ;
</pre></td></tr></table><P>

Suppose that the tokens `<SAMP>1 + 2</SAMP>' have been read and shifted; what
should be done?  If the following token is `<SAMP>)</SAMP>', then the first three
tokens must be reduced to form an <CODE>expr</CODE>.  This is the only valid
course, because shifting the `<SAMP>)</SAMP>' would produce a sequence of symbols
<CODE>term ')'</CODE>, and no rule allows this.
</P>
<P>

If the following token is `<SAMP>!</SAMP>', then it must be shifted immediately so
that `<SAMP>2 !</SAMP>' can be reduced to make a <CODE>term</CODE>.  If instead the
parser were to reduce before shifting, `<SAMP>1 + 2</SAMP>' would become an
<CODE>expr</CODE>.  It would then be impossible to shift the `<SAMP>!</SAMP>' because
doing so would produce on the stack the sequence of symbols <CODE>expr
'!'</CODE>.  No rule allows that sequence.
</P>
<P>

<A NAME="IDX34"></A>
The current look-ahead token is stored in the variable <CODE>yychar</CODE>.
See section <A HREF="bison_7.html#SEC66">Special Features for Use in Actions</A>.
</P>
<P>

<A NAME="Shift/Reduce"></A>
<HR SIZE="6">
<A NAME="SEC69"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC68"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC70"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H2> 5.2 Shift/Reduce Conflicts </H2>
<!--docid::SEC69::-->
<P>

Suppose we are parsing a language which has if-then and if-then-else
statements, with a pair of rules like this:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>if_stmt:
          IF expr THEN stmt
        | IF expr THEN stmt ELSE stmt
        ;
</pre></td></tr></table><P>

Here we assume that <CODE>IF</CODE>, <CODE>THEN</CODE> and <CODE>ELSE</CODE> are
terminal symbols for specific keyword tokens.
</P>
<P>

When the <CODE>ELSE</CODE> token is read and becomes the look-ahead token, the
contents of the stack (assuming the input is valid) are just right for
reduction by the first rule.  But it is also legitimate to shift the
<CODE>ELSE</CODE>, because that would lead to eventual reduction by the second
rule.
</P>
<P>

This situation, where either a shift or a reduction would be valid, is
called a <EM>shift/reduce conflict</EM>.  Bison is designed to resolve
these conflicts by choosing to shift, unless otherwise directed by
operator precedence declarations.  To see the reason for this, let's
contrast it with the other alternative.
</P>
<P>

Since the parser prefers to shift the <CODE>ELSE</CODE>, the result is to attach
the else-clause to the innermost if-statement, making these two inputs
equivalent:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>if x then if y then win (); else lose;

if x then do; if y then win (); else lose; end;
</pre></td></tr></table><P>

But if the parser chose to reduce when possible rather than shift, the
result would be to attach the else-clause to the outermost if-statement,
making these two inputs equivalent:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>if x then if y then win (); else lose;

if x then do; if y then win (); end; else lose;
</pre></td></tr></table><P>

The conflict exists because the grammar as written is ambiguous: either
parsing of the simple nested if-statement is legitimate.  The established
convention is that these ambiguities are resolved by attaching the
else-clause to the innermost if-statement; this is what Bison accomplishes
by choosing to shift rather than reduce.  (It would ideally be cleaner to
write an unambiguous grammar, but that is very hard to do in this case.)
This particular ambiguity was first encountered in the specifications of
Algol 60 and is called the &quot;dangling <CODE>else</CODE>&quot; ambiguity.
</P>
<P>

To avoid warnings from Bison about predictable, legitimate shift/reduce
conflicts, use the <CODE>%expect <VAR>n</VAR></CODE> declaration.  There will be no
warning as long as the number of shift/reduce conflicts is exactly <VAR>n</VAR>.
See section <A HREF="bison_6.html#SEC53">Suppressing Conflict Warnings</A>.
</P>
<P>

The definition of <CODE>if_stmt</CODE> above is solely to blame for the
conflict, but the conflict does not actually appear without additional
rules.  Here is a complete Bison input file that actually manifests the
conflict:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>%token IF THEN ELSE variable
%%
stmt:     expr
        | if_stmt
        ;

if_stmt:
          IF expr THEN stmt
        | IF expr THEN stmt ELSE stmt
        ;

expr:     variable
        ;
</pre></td></tr></table><P>

<A NAME="Precedence"></A>
<HR SIZE="6">
<A NAME="SEC70"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC69"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC71"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H2> 5.3 Operator Precedence </H2>
<!--docid::SEC70::-->
<P>

Another situation where shift/reduce conflicts appear is in arithmetic
expressions.  Here shifting is not always the preferred resolution; the
Bison declarations for operator precedence allow you to specify when to
shift and when to reduce.
</P>
<P>

<TABLE BORDER="0" CELLSPACING="0">
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="bison_8.html#SEC71">5.3.1 When Precedence is Needed</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">An example showing why precedence is needed.</TD></TR>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="bison_8.html#SEC72">5.3.2 Specifying Operator Precedence</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">How to specify precedence in Bison grammars.</TD></TR>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="bison_8.html#SEC73">5.3.3 Precedence Examples</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">How these features are used in the previous example.</TD></TR>
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="bison_8.html#SEC74">5.3.4 How Precedence Works</A></TD><TD>&nbsp;&nbsp;</TD><TD ALIGN="left" VALIGN="TOP">How they work.</TD></TR>
</TABLE>
<P>

<A NAME="Why Precedence"></A>
<HR SIZE="6">
<A NAME="SEC71"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC70"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC72"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC70"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H3> 5.3.1 When Precedence is Needed </H3>
<!--docid::SEC71::-->
<P>

Consider the following ambiguous grammar fragment (ambiguous because the
input `<SAMP>1 - 2 * 3</SAMP>' can be parsed in two different ways):
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>expr:     expr '-' expr
        | expr '*' expr
        | expr '&lt;' expr
        | '(' expr ')'
        <small>...</small>
        ;
</pre></td></tr></table><P>

Suppose the parser has seen the tokens `<SAMP>1</SAMP>', `<SAMP>-</SAMP>' and `<SAMP>2</SAMP>';
should it reduce them via the rule for the addition operator?  It depends
on the next token.  Of course, if the next token is `<SAMP>)</SAMP>', we must
reduce; shifting is invalid because no single rule can reduce the token
sequence `<SAMP>- 2 )</SAMP>' or anything starting with that.  But if the next
token is `<SAMP>*</SAMP>' or `<SAMP>&lt;</SAMP>', we have a choice: either shifting or
reduction would allow the parse to complete, but with different
results.
</P>
<P>

To decide which one Bison should do, we must consider the
results.  If the next operator token <VAR>op</VAR> is shifted, then it
must be reduced first in order to permit another opportunity to
reduce the sum.  The result is (in effect) `<SAMP>1 - (2
<VAR>op</VAR> 3)</SAMP>'.  On the other hand, if the subtraction is reduced
before shifting <VAR>op</VAR>, the result is `<SAMP>(1 - 2) <VAR>op</VAR>
3</SAMP>'.  Clearly, then, the choice of shift or reduce should depend
on the relative precedence of the operators `<SAMP>-</SAMP>' and
<VAR>op</VAR>: `<SAMP>*</SAMP>' should be shifted first, but not `<SAMP>&lt;</SAMP>'.
</P>
<P>

<A NAME="IDX35"></A>
What about input such as `<SAMP>1 - 2 - 5</SAMP>'; should this be
`<SAMP>(1 - 2) - 5</SAMP>' or should it be `<SAMP>1 - (2 - 5)</SAMP>'?  For
most operators we prefer the former, which is called <EM>left
association</EM>.  The latter alternative, <EM>right association</EM>, is
desirable for assignment operators.  The choice of left or right
association is a matter of whether the parser chooses to shift or
reduce when the stack contains `<SAMP>1 - 2</SAMP>' and the look-ahead
token is `<SAMP>-</SAMP>': shifting makes right-associativity.
</P>
<P>

<A NAME="Using Precedence"></A>
<HR SIZE="6">
<A NAME="SEC72"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC71"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC73"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC70"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H3> 5.3.2 Specifying Operator Precedence </H3>
<!--docid::SEC72::-->
<P>

Bison allows you to specify these choices with the operator precedence
declarations <CODE>%left</CODE> and <CODE>%right</CODE>.  Each such declaration
contains a list of tokens, which are operators whose precedence and
associativity is being declared.  The <CODE>%left</CODE> declaration makes all
those operators left-associative and the <CODE>%right</CODE> declaration makes
them right-associative.  A third alternative is <CODE>%nonassoc</CODE>, which
declares that it is a syntax error to find the same operator twice &quot;in a
row&quot;.
</P>
<P>

The relative precedence of different operators is controlled by the
order in which they are declared.  The first <CODE>%left</CODE> or
<CODE>%right</CODE> declaration in the file declares the operators whose
precedence is lowest, the next such declaration declares the operators
whose precedence is a little higher, and so on.
</P>
<P>

<A NAME="Precedence Examples"></A>
<HR SIZE="6">
<A NAME="SEC73"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC72"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC74"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC70"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H3> 5.3.3 Precedence Examples </H3>
<!--docid::SEC73::-->
<P>

In our example, we would want the following declarations:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>%left '&lt;'
%left '-'
%left '*'
</pre></td></tr></table><P>

In a more complete example, which supports other operators as well, we
would declare them in groups of equal precedence.  For example, <CODE>'+'</CODE> is
declared with <CODE>'-'</CODE>:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>%left '&lt;' '&gt;' '=' NE LE GE
%left '+' '-'
%left '*' '/'
</pre></td></tr></table><P>

(Here <CODE>NE</CODE> and so on stand for the operators for &quot;not equal&quot;
and so on.  We assume that these tokens are more than one character long
and therefore are represented by names, not character literals.)
</P>
<P>

<A NAME="How Precedence"></A>
<HR SIZE="6">
<A NAME="SEC74"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC73"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC75"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC70"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H3> 5.3.4 How Precedence Works </H3>
<!--docid::SEC74::-->
<P>

The first effect of the precedence declarations is to assign precedence
levels to the terminal symbols declared.  The second effect is to assign
precedence levels to certain rules: each rule gets its precedence from the
last terminal symbol mentioned in the components.  (You can also specify
explicitly the precedence of a rule.  See section <A HREF="bison_8.html#SEC75">Context-Dependent Precedence</A>.)
</P>
<P>

Finally, the resolution of conflicts works by comparing the
precedence of the rule being considered with that of the
look-ahead token.  If the token's precedence is higher, the
choice is to shift.  If the rule's precedence is higher, the
choice is to reduce.  If they have equal precedence, the choice
is made based on the associativity of that precedence level.  The
verbose output file made by `<SAMP>-v</SAMP>' (see section <A HREF="bison_12.html#SEC86">Invoking Bison</A>) says
how each conflict was resolved.
</P>
<P>

Not all rules and not all tokens have precedence.  If either the rule or
the look-ahead token has no precedence, then the default is to shift.
</P>
<P>

<A NAME="Contextual Precedence"></A>
<HR SIZE="6">
<A NAME="SEC75"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC74"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC76"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H2> 5.4 Context-Dependent Precedence </H2>
<!--docid::SEC75::-->
<P>

Often the precedence of an operator depends on the context.  This sounds
outlandish at first, but it is really very common.  For example, a minus
sign typically has a very high precedence as a unary operator, and a
somewhat lower precedence (lower than multiplication) as a binary operator.
</P>
<P>

The Bison precedence declarations, <CODE>%left</CODE>, <CODE>%right</CODE> and
<CODE>%nonassoc</CODE>, can only be used once for a given token; so a token has
only one precedence declared in this way.  For context-dependent
precedence, you need to use an additional mechanism: the <CODE>%prec</CODE>
modifier for rules.</P>
<P>

The <CODE>%prec</CODE> modifier declares the precedence of a particular rule by
specifying a terminal symbol whose precedence should be used for that rule.
It's not necessary for that symbol to appear otherwise in the rule.  The
modifier's syntax is:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>%prec <VAR>terminal-symbol</VAR>
</pre></td></tr></table><P>

and it is written after the components of the rule.  Its effect is to
assign the rule the precedence of <VAR>terminal-symbol</VAR>, overriding
the precedence that would be deduced for it in the ordinary way.  The
altered rule precedence then affects how conflicts involving that rule
are resolved (see section <A HREF="bison_8.html#SEC70">Operator Precedence</A>).
</P>
<P>

Here is how <CODE>%prec</CODE> solves the problem of unary minus.  First, declare
a precedence for a fictitious terminal symbol named <CODE>UMINUS</CODE>.  There
are no tokens of this type, but the symbol serves to stand for its
precedence:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre><small>...</small>
%left '+' '-'
%left '*'
%left UMINUS
</pre></td></tr></table><P>

Now the precedence of <CODE>UMINUS</CODE> can be used in specific rules:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>exp:    <small>...</small>
        | exp '-' exp
        <small>...</small>
        | '-' exp %prec UMINUS
</pre></td></tr></table><P>

<A NAME="Parser States"></A>
<HR SIZE="6">
<A NAME="SEC76"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC75"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC77"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H2> 5.5 Parser States </H2>
<!--docid::SEC76::-->
<P>

The function <CODE>yyparse</CODE> is implemented using a finite-state machine.
The values pushed on the parser stack are not simply token type codes; they
represent the entire sequence of terminal and nonterminal symbols at or
near the top of the stack.  The current state collects all the information
about previous input which is relevant to deciding what to do next.
</P>
<P>

Each time a look-ahead token is read, the current parser state together
with the type of look-ahead token are looked up in a table.  This table
entry can say, &quot;Shift the look-ahead token.&quot;  In this case, it also
specifies the new parser state, which is pushed onto the top of the
parser stack.  Or it can say, &quot;Reduce using rule number <VAR>n</VAR>.&quot;
This means that a certain number of tokens or groupings are taken off
the top of the stack, and replaced by one grouping.  In other words,
that number of states are popped from the stack, and one new state is
pushed.
</P>
<P>

There is one other alternative: the table can say that the look-ahead token
is erroneous in the current state.  This causes error processing to begin
(see section <A HREF="bison_9.html#SEC80">6. Error Recovery</A>).
</P>
<P>

<A NAME="Reduce/Reduce"></A>
<HR SIZE="6">
<A NAME="SEC77"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC76"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC78"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H2> 5.6 Reduce/Reduce Conflicts </H2>
<!--docid::SEC77::-->
<P>

A reduce/reduce conflict occurs if there are two or more rules that apply
to the same sequence of input.  This usually indicates a serious error
in the grammar.
</P>
<P>

For example, here is an erroneous attempt to define a sequence
of zero or more <CODE>word</CODE> groupings.
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>sequence: /* empty */
                { printf (&quot;empty sequence\n&quot;); }
        | maybeword
        | sequence word
                { printf (&quot;added word %s\n&quot;, $2); }
        ;

maybeword: /* empty */
                { printf (&quot;empty maybeword\n&quot;); }
        | word
                { printf (&quot;single word %s\n&quot;, $1); }
        ;
</pre></td></tr></table><P>

The error is an ambiguity: there is more than one way to parse a single
<CODE>word</CODE> into a <CODE>sequence</CODE>.  It could be reduced to a
<CODE>maybeword</CODE> and then into a <CODE>sequence</CODE> via the second rule.
Alternatively, nothing-at-all could be reduced into a <CODE>sequence</CODE>
via the first rule, and this could be combined with the <CODE>word</CODE>
using the third rule for <CODE>sequence</CODE>.
</P>
<P>

There is also more than one way to reduce nothing-at-all into a
<CODE>sequence</CODE>.  This can be done directly via the first rule,
or indirectly via <CODE>maybeword</CODE> and then the second rule.
</P>
<P>

You might think that this is a distinction without a difference, because it
does not change whether any particular input is valid or not.  But it does
affect which actions are run.  One parsing order runs the second rule's
action; the other runs the first rule's action and the third rule's action.
In this example, the output of the program changes.
</P>
<P>

Bison resolves a reduce/reduce conflict by choosing to use the rule that
appears first in the grammar, but it is very risky to rely on this.  Every
reduce/reduce conflict must be studied and usually eliminated.  Here is the
proper way to define <CODE>sequence</CODE>:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>sequence: /* empty */
                { printf (&quot;empty sequence\n&quot;); }
        | sequence word
                { printf (&quot;added word %s\n&quot;, $2); }
        ;
</pre></td></tr></table><P>

Here is another common error that yields a reduce/reduce conflict:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>sequence: /* empty */
        | sequence words
        | sequence redirects
        ;

words:    /* empty */
        | words word
        ;

redirects:/* empty */
        | redirects redirect
        ;
</pre></td></tr></table><P>

The intention here is to define a sequence which can contain either
<CODE>word</CODE> or <CODE>redirect</CODE> groupings.  The individual definitions of
<CODE>sequence</CODE>, <CODE>words</CODE> and <CODE>redirects</CODE> are error-free, but the
three together make a subtle ambiguity: even an empty input can be parsed
in infinitely many ways!
</P>
<P>

Consider: nothing-at-all could be a <CODE>words</CODE>.  Or it could be two
<CODE>words</CODE> in a row, or three, or any number.  It could equally well be a
<CODE>redirects</CODE>, or two, or any number.  Or it could be a <CODE>words</CODE>
followed by three <CODE>redirects</CODE> and another <CODE>words</CODE>.  And so on.
</P>
<P>

Here are two ways to correct these rules.  First, to make it a single level
of sequence:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>sequence: /* empty */
        | sequence word
        | sequence redirect
        ;
</pre></td></tr></table><P>

Second, to prevent either a <CODE>words</CODE> or a <CODE>redirects</CODE>
from being empty:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>sequence: /* empty */
        | sequence words
        | sequence redirects
        ;

words:    word
        | words word
        ;

redirects:redirect
        | redirects redirect
        ;
</pre></td></tr></table><P>

<A NAME="Mystery Conflicts"></A>
<HR SIZE="6">
<A NAME="SEC78"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC77"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC79"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H2> 5.7 Mysterious Reduce/Reduce Conflicts </H2>
<!--docid::SEC78::-->
<P>

Sometimes reduce/reduce conflicts can occur that don't look warranted.
Here is an example:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>%token ID

%%
def:    param_spec return_spec ','
        ;
param_spec:
             type
        |    name_list ':' type
        ;
return_spec:
             type
        |    name ':' type
        ;
type:        ID
        ;
name:        ID
        ;
name_list:
             name
        |    name ',' name_list
        ;
</pre></td></tr></table><P>

It would seem that this grammar can be parsed with only a single token
of look-ahead: when a <CODE>param_spec</CODE> is being read, an <CODE>ID</CODE> is 
a <CODE>name</CODE> if a comma or colon follows, or a <CODE>type</CODE> if another
<CODE>ID</CODE> follows.  In other words, this grammar is LR(1).
</P>
<P>

<A NAME="IDX36"></A>
<A NAME="IDX37"></A>
However, Bison, like most parser generators, cannot actually handle all
LR(1) grammars.  In this grammar, two contexts, that after an <CODE>ID</CODE>
at the beginning of a <CODE>param_spec</CODE> and likewise at the beginning of
a <CODE>return_spec</CODE>, are similar enough that Bison assumes they are the
same.  They appear similar because the same set of rules would be
active--the rule for reducing to a <CODE>name</CODE> and that for reducing to
a <CODE>type</CODE>.  Bison is unable to determine at that stage of processing
that the rules would require different look-ahead tokens in the two
contexts, so it makes a single parser state for them both.  Combining
the two contexts causes a conflict later.  In parser terminology, this
occurrence means that the grammar is not LALR(1).
</P>
<P>

In general, it is better to fix deficiencies than to document them.  But
this particular deficiency is intrinsically hard to fix; parser
generators that can handle LR(1) grammars are hard to write and tend to
produce parsers that are very large.  In practice, Bison is more useful
as it is now.
</P>
<P>

When the problem arises, you can often fix it by identifying the two
parser states that are being confused, and adding something to make them
look distinct.  In the above example, adding one rule to
<CODE>return_spec</CODE> as follows makes the problem go away:
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>%token BOGUS
<small>...</small>
%%
<small>...</small>
return_spec:
             type
        |    name ':' type
        /* This rule is never used.  */
        |    ID BOGUS
        ;
</pre></td></tr></table><P>

This corrects the problem because it introduces the possibility of an
additional active rule in the context after the <CODE>ID</CODE> at the beginning of
<CODE>return_spec</CODE>.  This rule is not active in the corresponding context
in a <CODE>param_spec</CODE>, so the two contexts receive distinct parser states.
As long as the token <CODE>BOGUS</CODE> is never generated by <CODE>yylex</CODE>,
the added rule cannot alter the way actual input is parsed.
</P>
<P>

In this particular example, there is another way to solve the problem:
rewrite the rule for <CODE>return_spec</CODE> to use <CODE>ID</CODE> directly
instead of via <CODE>name</CODE>.  This also causes the two confusing
contexts to have different sets of active rules, because the one for
<CODE>return_spec</CODE> activates the altered rule for <CODE>return_spec</CODE>
rather than the one for <CODE>name</CODE>.
</P>
<P>

<TABLE><tr><td>&nbsp;</td><td class=example><pre>param_spec:
             type
        |    name_list ':' type
        ;
return_spec:
             type
        |    ID ':' type
        ;
</pre></td></tr></table><P>

<A NAME="Stack Overflow"></A>
<HR SIZE="6">
<A NAME="SEC79"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC78"> &lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<H2> 5.8 Stack Overflow, and How to Avoid It </H2>
<!--docid::SEC79::-->
<P>

The Bison parser stack can overflow if too many tokens are shifted and
not reduced.  When this happens, the parser function <CODE>yyparse</CODE>
returns a nonzero value, pausing only to call <CODE>yyerror</CODE> to report
the overflow.
</P>
<P>

<A NAME="IDX38"></A>
By defining the macro <CODE>YYMAXDEPTH</CODE>, you can control how deep the
parser stack can become before a stack overflow occurs.  Define the
macro with a value that is an integer.  This value is the maximum number
of tokens that can be shifted (and not reduced) before overflow.
It must be a constant expression whose value is known at compile time.
</P>
<P>

The stack space allowed is not necessarily allocated.  If you specify a
large value for <CODE>YYMAXDEPTH</CODE>, the parser actually allocates a small
stack at first, and then makes it bigger by stages as needed.  This
increasing allocation happens automatically and silently.  Therefore,
you do not need to make <CODE>YYMAXDEPTH</CODE> painfully small merely to save
space for ordinary inputs that do not need much stack.
</P>
<P>

<A NAME="IDX39"></A>
The default value of <CODE>YYMAXDEPTH</CODE>, if you do not define it, is
10000.
</P>
<P>

<A NAME="IDX40"></A>
You can control how much stack is allocated initially by defining the
macro <CODE>YYINITDEPTH</CODE>.  This value too must be a compile-time
constant integer.  The default is 200.
</P>
<P>

<A NAME="Error Recovery"></A>
<HR SIZE="6">
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_8.html#SEC67"> &lt;&lt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_9.html#SEC80"> &gt;&gt; </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_15.html#SEC92">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="bison_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<BR>
<FONT SIZE="-1">
This document was generated
by <I>Frank B. Brokken</I> on <I>January, 28 2005</I>
using <A HREF="http://texi2html.cvshome.org"><I>texi2html</I></A>
</FONT>

</BODY>
</HTML>