-.DE
-The first line describes the conflict, giving the state and the input symbol.
-The state title follows, and a brief description of the grammar
-rules which are active in this state.
-The underline ``\_'' describes the
-portions of the grammar rules which have been seen.
-Thus in the example, in state 23 we have seen input which corresponds
-to
-.DS
-IF ( cond ) stat
-.DE
-and the two grammar rules shown are active at this time.
-The actions possible are, if the input symbol is ELSE, we may shift into state
-45.
-In this state, we should find as part of the description a line of the form
-.DS
-stat : IF ( cond ) stat ELSE\_stat
-.DE
-because in this state we will have read and shifted the ELSE.
-Back in state 23, the alternative action, described by ``.'',
-is to be done if the input symbol is not mentioned explicitly in the above actions; thus,
-in this case, if the input symbol is not ELSE, we should reduce by grammar rule 18,
-which is presumably
-.DS
-stat : IF \'(\' cond \')\' stat
-.DE
-Notice that the numbers following ``shift'' commands refer to other states,
-while the numbers following ``reduce'' commands refer to grammar
-rule numbers.
-In most states, there will be only one reduce action possible in the
-state, and this will always be the default command.
-The user who encounters unexpected shift/reduce conflicts will probably want to
-look at the verbose output to decide whether the default actions are appropriate.
-In really tough cases, the user might need to know more about
-the behavior and construction of the parser than can be covered here;
-in this case, a reference such as [1]
-might be consulted; the services of a local guru might also be appropriate.
-.PP
-There is one common situation
-where the rules given above for resolving conflicts are not sufficient;
-this is in the area of arithmetic expressions.
-Most of the commonly used constructions for arithmetic expressions can be naturally
-described by the notion of
-.ul
-precedence
-levels for operators, together with information about left
-or right associativity.
-It turns out that ambiguous grammars with appropriate disambiguating rules
-can be used to create parsers which are faster and easier to
-write than parsers constructed from unambiguous grammars.
-The basic notion is to write grammar rules
-of the form
-.DS
-expr : expr OP expr
-.DE
-and
-.DS
-expr : UNARY expr
-.DE
-for all binary and unary operators desired.
-This creates a very ambiguous grammar, with many parsing conflicts.
-As disambiguating rules, the user specifies the precedence, or binding
-strength, of all the operators, and the associativity
-of the binary operators.
-This information is sufficient to allow Yacc to resolve the parsing conflicts
-in accordance with these rules, and construct a parser which realizes the desired
-precedences and associativities.
-.PP
-The precedences and associativities are attached to tokens in the declarations section.
-This is done by a series of lines beginning with a Yacc keyword: %left, %right,
-or %nonassoc, followed by a list of tokens.
-All of the tokens on the same line are assumed to have the same precedence level
-and associativity; the lines are listed in
-order of increasing precedence or binding strength.
-Thus,
-.DS
-%left \'+\' \'\-\'
-%left \'*\' \'/\'
-.DE
-describes the precedence and associativity of the four arithmetic operators.
-Plus and minus are left associative, and have lower precedence than
-star and slash, which are also left associative.
-The keyword %right is used to describe right associative operators,
-and the keyword %nonassoc is used to describe operators, like
-the operator .LT. in Fortran, which may not associate with themselves; thus,
-.DS
-A .LT. B .LT. C
-.DE
-is illegal in Fortran, and such an operator would be described with the keyword
-%nonassoc in Yacc.
-As an example of the behavior of these declarations, the description
-.DS
-%right \'=\'
-%left \'+\' \'\-\'
-%left \'*\' \'/\'
projects / unix-history / blobdiff