home *** CD-ROM | disk | FTP | other *** search
/ The C Users' Group Library 1994 August / wc-cdrom-cusersgrouplibrary-1994-08.iso / vol_200 / 285_01 / bisoninf.3 < prev    next >
Text File  |  1990-07-09  |  50KB  |  1,335 lines
  1. Info file bison.info, produced by Makeinfo, -*- Text -*- from input
  2. file bison.texinfo.
  3.  
  4. This file documents the Bison parser generator.
  5.  
  6. Copyright (C) 1988 Free Software Foundation, Inc.
  7.  
  8. Permission is granted to make and distribute verbatim copies of this
  9. manual provided the copyright notice and this permission notice are
  10. preserved on all copies.
  11.  
  12. Permission is granted to copy and distribute modified versions of
  13. this manual under the conditions for verbatim copying, provided also
  14. that the sections entitled ``Bison General Public License'' and
  15. ``Conditions for Using Bison'' are included exactly as in the
  16. original, and provided that the entire resulting derived work is
  17. distributed under the terms of a permission notice identical to this
  18. one.
  19.  
  20. Permission is granted to copy and distribute translations of this
  21. manual into another language, under the above conditions for modified
  22. versions, except that the text of the translations of the sections
  23. entitled ``Bison General Public License'' and ``Conditions for Using
  24. Bison'' must be approved for accuracy by the Foundation.
  25.  
  26.  
  27.  
  28. File: bison.info,  Node: Action Features,  Prev: Error Reporting,  Up: Interface
  29.  
  30. Special Features for Use in Actions
  31. ===================================
  32.  
  33. Here is a table of Bison constructs, variables and macros that are
  34. useful in actions.
  35.  
  36. `$$'
  37.      Acts like a variable that contains the semantic value for the
  38.      grouping made by the current rule.  *Note Actions::.
  39.  
  40. `$N'
  41.      Acts like a variable that contains the semantic value for the
  42.      Nth component of the current rule.  *Note Actions::.
  43.  
  44. `$<TYPEALT>$'
  45.      Like `$$' but specifies alternative TYPEALT in the union
  46.      specified by the `%union' declaration.  *Note Action Types::.
  47.  
  48. `$<TYPEALT>N'
  49.      Like `$N' but specifies alternative TYPEALT in the union
  50.      specified by the `%union' declaration.  *Note Action Types::.
  51.  
  52. `YYABORT;'
  53.      Return immediately from `yyparse', indicating failure.  *Note
  54.      Parser Function::.
  55.  
  56. `YYACCEPT;'
  57.      Return immediately from `yyparse', indicating success.  *Note
  58.      Parser Function::.
  59.  
  60. `YYEMPTY'
  61.      Value stored in `yychar' when there is no look-ahead token.
  62.  
  63. `YYERROR;'
  64.      Cause an immediate syntax error.  This causes `yyerror' to be
  65.      called, and then error recovery begins.  *Note Error Recovery::.
  66.  
  67. `yychar'
  68.      Variable containing the current look-ahead token.  When there is
  69.      no look-ahead token, the value `YYERROR' is stored here.  *Note
  70.      Look-Ahead::.
  71.  
  72. `yyclearin;'
  73.      Discard the current look-ahead token.  This is useful primarily
  74.      in error rules.  *Note Error Recovery::.
  75.  
  76. `yyerrok;'
  77.      Resume generating error messages immediately for subsequent
  78.      syntax errors.  This is useful primarily in error rules.  *Note
  79.      Error Recovery::.
  80.  
  81. `@N'
  82.      Acts like a structure variable containing information on the
  83.      line numbers and column numbers of the Nth component of the
  84.      current rule.  The structure has four members, like this:
  85.  
  86.           struct {
  87.             int first_line, last_line;
  88.             int first_column, last_column;
  89.           };
  90.  
  91.      Thus, to get the starting line number of the third component,
  92.      use `@3.first_line'.
  93.  
  94.      In order for the members of this structure to contain valid
  95.      information, you must make `yylex' supply this information about
  96.      each token.  If you need only certain members, then `yylex' need
  97.      only fill in those members.
  98.  
  99.      The use of this feature makes the parser noticeably slower.
  100.  
  101.  
  102.  
  103. File: bison.info,  Node: Algorithm,  Next: Error Recovery,  Prev: Interface,  Up: Top
  104.  
  105. The Algorithm of the Bison Parser
  106. *********************************
  107.  
  108. As Bison reads tokens, it pushes them onto a stack along with their
  109. semantic values.  The stack is called the "parser stack".  Pushing a
  110. token is traditionally called "shifting".
  111.  
  112. For example, suppose the infix calculator has read `1 + 5 *', with a
  113. `3' to come.  The stack will have four elements, one for each token
  114. that was shifted.
  115.  
  116. But the stack does not always have an element for each token read. 
  117. When the last N tokens and groupings shifted match the components of
  118. a grammar rule, they can be combined according to that rule.  This is
  119. called "reduction".  Those tokens and groupings are replaced on the
  120. stack by a single grouping whose symbol is the result (left hand
  121. side) of that rule.  Running the rule's action is part of the process
  122. of reduction, because this is what computes the semantic value of the
  123. resulting grouping.
  124.  
  125. For example, if the infix calculator's parser stack contains this:
  126.  
  127.      1 + 5 * 3
  128.  
  129. and the next input token is a newline character, then the last three
  130. elements can be reduced to 15 via the rule:
  131.  
  132.      expr: expr '*' expr;
  133.  
  134. Then the stack contains just these three elements:
  135.  
  136.      1 + 15
  137.  
  138. At this point, another reduction can be made, resulting in the single
  139. value 16.  Then the newline token can be shifted.
  140.  
  141. The parser tries, by shifts and reductions, to reduce the entire
  142. input down to a single grouping whose symbol is the grammar's
  143. start-symbol (*note Language and Grammar::.).
  144.  
  145. This kind of parser is known in the literature as a bottom-up parser.
  146.  
  147. * Menu:
  148.  
  149. * Look-Ahead::          Parser looks one token ahead when deciding what to do.
  150. * Shift/Reduce::        Conflicts: when either shifting or reduction is valid.
  151. * Precedence::          Operator precedence works by resolving conflicts.
  152. * Contextual Precedence:: When an operator's precedence depends on context.
  153. * Parser States::       The parser is a finite-state-machine with stack.
  154. * Reduce/Reduce::       When two rules are applicable in the same situation.
  155.  
  156.  
  157.  
  158. File: bison.info,  Node: Look-Ahead,  Next: Shift/Reduce,  Prev: Algorithm,  Up: Algorithm
  159.  
  160. Look-Ahead Tokens
  161. =================
  162.  
  163. The Bison parser does *not* always reduce immediately as soon as the
  164. last N tokens and groupings match a rule.  This is because such a
  165. simple strategy is inadequate to handle most languages.  Instead,
  166. when a reduction is possible, the parser sometimes ``looks ahead'' at
  167. the next token in order to decide what to do.
  168.  
  169. When a token is read, it is not immediately shifted; first it becomes
  170. the "look-ahead token", which is not on the stack.  Now the parser
  171. can perform one or more reductions of tokens and groupings on the
  172. stack, while the look-ahead token remains off to the side.  When no
  173. more reductions should take place, the look-ahead token is shifted
  174. onto the stack.  This does not mean that all possible reductions have
  175. been done; depending on the token type of the look-ahead token, some
  176. rules may choose to delay their application.
  177.  
  178. Here is a simple case where look-ahead is needed.  These three rules
  179. define expressions which contain binary addition operators and
  180. postfix unary factorial operators (`!'), and allow parentheses for
  181. grouping.
  182.  
  183.      expr:     term '+' expr
  184.              | term
  185.              ;
  186.      
  187.      term:     '(' expr ')'
  188.              | term '!'
  189.              | NUMBER
  190.              ;
  191.  
  192. Suppose that the tokens `1 + 2' have been read and shifted; what
  193. should be done?  If the following token is `)', then the first three
  194. tokens must be reduced to form an `expr'.  This is the only valid
  195. course, because shifting the `)' would produce a sequence of symbols
  196. `term ')'', and no rule allows this.
  197.  
  198. If the following token is `!', then it must be shifted immediately so
  199. that `2 !' can be reduced to make a `term'.  If instead the parser
  200. were to reduce before shifting, `1 + 2' would become an `expr'.  It
  201. would then be impossible to shift the `!' because doing so would
  202. produce on the stack the sequence of symbols `expr '!''.  No rule
  203. allows that sequence.
  204.  
  205. The current look-ahead token is stored in the variable `yychar'. 
  206. *Note Action Features::.
  207.  
  208.  
  209.  
  210. File: bison.info,  Node: Shift/Reduce,  Next: Precedence,  Prev: Look-Ahead,  Up: Algorithm
  211.  
  212. Shift/Reduce Conflicts
  213. ======================
  214.  
  215. Suppose we are parsing a language which has if-then and if-then-else
  216. statements, with a pair of rules like this:
  217.  
  218.      if_stmt:
  219.                IF expr THEN stmt
  220.              | IF expr THEN stmt ELSE stmt
  221.              ;
  222.  
  223. (Here we assume that `IF', `THEN' and `ELSE' are terminal symbols for
  224. specific keyword tokens.)
  225.  
  226. When the `ELSE' token is read and becomes the look-ahead token, the
  227. contents of the stack (assuming the input is valid) are just right
  228. for reduction by the first rule.  But it is also legitimate to shift
  229. the `ELSE', because that would lead to eventual reduction by the
  230. second rule.
  231.  
  232. This situation, where either a shift or a reduction would be valid,
  233. is called a "shift/reduce conflict".  Bison is designed to resolve
  234. these conflicts by choosing to shift, unless otherwise directed by
  235. operator precedence declarations.  To see the reason for this, let's
  236. contrast it with the other alternative.
  237.  
  238. Since the parser prefers to shift the `ELSE', the result is to attach
  239. the else-clause to the innermost if-statement, making these two
  240. inputs equivalent:
  241.  
  242.      if x then if y then win(); else lose;
  243.      
  244.      if x then do; if y then win(); else lose; end;
  245.  
  246. But if the parser chose to reduce when possible rather than shift,
  247. the result would be to attach the else-clause to the outermost
  248. if-statement, making these two inputs equivalent:
  249.  
  250.      if x then if y then win(); else lose;
  251.      
  252.      if x then do; if y then win(); end; else lose;
  253.  
  254. The conflict exists because the grammar as written is ambiguous:
  255. either parsing of the simple nested if-statement is legitimate.  The
  256. established convention is that these ambiguities are resolved by
  257. attaching the else-clause to the innermost if-statement; this is what
  258. Bison accomplishes by choosing to shift rather than reduce.  (It
  259. would ideally be cleaner to write an unambiguous grammar, but that is
  260. very hard to do in this case.) This particular ambiguity was first
  261. encountered in the specifications of Algol 60 and is called the
  262. ``dangling `else''' ambiguity.
  263.  
  264. To avoid warnings from Bison about predictable, legitimate
  265. shift/reduce conflicts, use the `%expect N' declaration.  There will
  266. be no warning as long as the number of shift/reduce conflicts is
  267. exactly N.  *Note Expect Decl::.
  268.  
  269.  
  270.  
  271. File: bison.info,  Node: Precedence,  Next: Contextual Precedence,  Prev: Shift/Reduce,  Up: Algorithm
  272.  
  273. Operator Precedence
  274. ===================
  275.  
  276. Another situation where shift/reduce conflicts appear is in
  277. arithmetic expressions.  Here shifting is not always the preferred
  278. resolution; the Bison declarations for operator precedence allow you
  279. to specify when to shift and when to reduce.
  280.  
  281. * Menu:
  282.  
  283. * Why Precedence::      An example showing why precedence is needed.
  284. * Using Precedence::    How to specify precedence in Bison grammars.
  285. * Precedence Examples:: How these features are used in the previous example.
  286. * How Precedence::      How they work.
  287.  
  288.  
  289.  
  290. File: bison.info,  Node: Why Precedence,  Next: Using Precedence,  Prev: Precedence,  Up: Precedence
  291.  
  292. When Precedence is Needed
  293. -------------------------
  294.  
  295. Consider the following ambiguous grammar fragment (ambiguous because
  296. the input `1 - 2 * 3' can be parsed in two different ways):
  297.  
  298.      expr:     expr '-' expr
  299.              | expr '*' expr
  300.              | expr '<' expr
  301.              | '(' expr ')'
  302.              ...
  303.              ;
  304.  
  305. Suppose the parser has seen the tokens `1', `-' and `2'; should it
  306. reduce them via the rule for the addition operator?  It depends on
  307. the next token.  Of course, if the next token is `)', we must reduce;
  308. shifting is invalid because no single rule can reduce the token
  309. sequence `- 2 )' or anything starting with that.  But if the next
  310. token is `*' or `<', we have a choice: either shifting or reduction
  311. would allow the parse to complete, but with different results.
  312.  
  313. To decide which one Bison should do, we must consider the results. 
  314. If the next operator token OP is shifted, then it must be reduced
  315. first in order to permit another opportunity to reduce the sum.  The
  316. result is (in effect) `1 - (2 OP 3)'.  On the other hand, if the
  317. subtraction is reduced before shifting OP, the result is
  318. `(1 - 2) OP 3'.  Clearly, then, the choice of shift or reduce
  319. should depend on the relative precedence of the operators `-' and OP:
  320. `*' should be shifted first, but not `<'.
  321.  
  322. What about input like `1 - 2 - 5'; should this be `(1 - 2) - 5' or
  323. `1 - (2 - 5)'?  For most operators we prefer the former, which is
  324. called "left association".  The latter alternative, "right
  325. association", is desirable for assignment operators.  The choice of
  326. left or right association is a matter of whether the parser chooses
  327. to shift or reduce when the stack contains `1 - 2' and the look-ahead
  328. token is `-': shifting makes right-associativity.
  329.  
  330.  
  331.  
  332. File: bison.info,  Node: Using Precedence,  Next: Precedence Examples,  Prev: Why Precedence,  Up: Precedence
  333.  
  334. How to Specify Operator Precedence
  335. ----------------------------------
  336.  
  337. Bison allows you to specify these choices with the operator
  338. precedence declarations `%left' and `%right'.  Each such declaration
  339. contains a list of tokens, which are operators whose precedence and
  340. associativity is being declared.  The `%left' declaration makes all
  341. those operators left-associative and the `%right' declaration makes
  342. them right-associative.  A third alternative is `%nonassoc', which
  343. declares that it is a syntax error to find the same operator twice
  344. ``in a row''.
  345.  
  346. The relative precedence of different operators is controlled by the
  347. order in which they are declared.  The first `%left' or `%right'
  348. declaration declares the operators whose precedence is lowest, the
  349. next such declaration declares the operators whose precedence is a
  350. little higher, and so on.
  351.  
  352.  
  353.  
  354. File: bison.info,  Node: Precedence Examples,  Next: How Precedence,  Prev: Using Precedence,  Up: Precedence
  355.  
  356. Precedence Examples
  357. -------------------
  358.  
  359. In our example, we would want the following declarations:
  360.  
  361.      %left '<'
  362.      %left '-'
  363.      %left '*'
  364.  
  365. In a more complete example, which supports other operators as well,
  366. we would declare them in groups of equal precedence.  For example,
  367. `'+'' is declared with `'-'':
  368.  
  369.      %left '<' '>' '=' NE LE GE
  370.      %left '+' '-'
  371.      %left '*' '/'
  372.  
  373. (Here `NE' and so on stand for the operators for ``not equal'' and so
  374. on.  We assume that these tokens are more than one character long and
  375. therefore are represented by names, not character literals.)
  376.  
  377.  
  378.  
  379. File: bison.info,  Node: How Precedence,  Prev: Precedence Examples,  Up: Precedence
  380.  
  381. How Precedence Works
  382. --------------------
  383.  
  384. The first effect of the precedence declarations is to assign
  385. precedence levels to the terminal symbols declared.  The second
  386. effect is to assign precedence levels to certain rules: each rule
  387. gets its precedence from the last terminal symbol mentioned in the
  388. components.  (You can also specify explicitly the precedence of a
  389. rule.  *Note Contextual Precedence::.)
  390.  
  391. Finally, the resolution of conflicts works by comparing the
  392. precedence of the rule being considered with that of the look-ahead
  393. token.  If the token's precedence is higher, the choice is to shift. 
  394. If the rule's precedence is higher, the choice is to reduce.  If they
  395. have equal precedence, the choice is made based on the associativity
  396. of that precedence level.  The verbose output file made by `-v'
  397. (*note Invocation::.) says how each conflict was resolved.
  398.  
  399. Not all rules and not all tokens have precedence.  If either the rule
  400. or the look-ahead token has no precedence, then the default is to
  401. shift.
  402.  
  403.  
  404.  
  405. File: bison.info,  Node: Contextual Precedence,  Next: Parser States,  Prev: Precedence,  Up: Algorithm
  406.  
  407. Operators with Context-Dependent Precedence
  408. ===========================================
  409.  
  410. Often the precedence of an operator depends on the context.  This
  411. sounds outlandish at first, but it is really very common.  For
  412. example, a minus sign typically has a very high precedence as a unary
  413. operator, and a somewhat lower precedence (lower than multiplication)
  414. as a binary operator.
  415.  
  416. The Bison precedence declarations, `%left', `%right' and `%nonassoc',
  417. can only be used once for a given token; so a token has only one
  418. precedence declared in this way.  For context-dependent precedence,
  419. you need to use an additional mechanism: the `%prec' modifier for
  420. rules.
  421.  
  422. The `%prec' modifier declares the precedence of a particular rule by
  423. specifying a terminal symbol whose predecence should be used for that
  424. rule.  It's not necessary for that symbol to appear otherwise in the
  425. rule.  The modifier's syntax is:
  426.  
  427.      %prec TERMINAL-SYMBOL
  428.  
  429. and it is written after the components of the rule.  Its effect is to
  430. assign the rule the precedence of TERMINAL-SYMBOL, overriding the
  431. precedence that would be deduced for it in the ordinary way.  The
  432. altered rule precedence then affects how conflicts involving that
  433. rule are resolved (*note Precedence::.).
  434.  
  435. Here is how `%prec' solves the problem of unary minus.  First,
  436. declare a precedence for a fictitious terminal symbol named `UMINUS'.
  437. There are no tokens of this type, but the symbol serves to stand for
  438. its precedence:
  439.  
  440.      ...
  441.      %left '+' '-'
  442.      %left '*'
  443.      %left UMINUS
  444.  
  445. Now the precedence of `UMINUS' can be used in specific rules:
  446.  
  447.      exp:    ...
  448.              | exp '-' exp
  449.              ...
  450.              | '-' exp %prec UMINUS
  451.  
  452.  
  453.  
  454. File: bison.info,  Node: Parser States,  Next: Reduce/Reduce,  Prev: Contextual Precedence,  Up: Algorithm
  455.  
  456. Parser States
  457. =============
  458.  
  459. The function `yyparse' is implemented using a finite-state machine. 
  460. The values pushed on the parser stack are not simply token type
  461. codes; they represent the entire sequence of terminal and nonterminal
  462. symbols at or near the top of the stack.  The current state collects
  463. all the information about previous input which is relevant to
  464. deciding what to do next.
  465.  
  466. Each time a look-ahead token is read, the current parser state
  467. together with the type of look-ahead token are looked up in a table. 
  468. This table entry can say, ``Shift the look-ahead token.''  In this
  469. case, it also specifies the new parser state, which is pushed onto
  470. the top of the parser stack.  Or it can say, ``Reduce using rule
  471. number N.'' This means that a certain of tokens or groupings are
  472. taken off the top of the stack, and replaced by one grouping.  In
  473. other words, that number of states are popped from the stack, and one
  474. new state is pushed.
  475.  
  476. There is one other alternative: the table can say that the look-ahead
  477. token is erroneous in the current state.  This causes error
  478. processing to begin (*note Error Recovery::.).
  479.  
  480.  
  481.  
  482. File: bison.info,  Node: Reduce/Reduce,  Prev: Parser States,  Up: Algorithm
  483.  
  484. Reduce/Reduce conflicts
  485. =======================
  486.  
  487. A reduce/reduce conflict occurs if there are two or more rules that
  488. apply to the same sequence of input.  This usually indicates a
  489. serious error in the grammar.
  490.  
  491. For example, here is an erroneous attempt to define a sequence of
  492. zero or more `word' groupings.
  493.  
  494.      sequence: /* empty */
  495.                      { printf ("empty sequence\n"); }
  496.              | word
  497.                      { printf ("single word %s\n", $1); }
  498.              | sequence word
  499.                      { printf ("added word %s\n", $2); }
  500.              ;
  501.  
  502. The error is an ambiguity: there is more than one way to parse a
  503. single `word' into a `sequence'.  It could be reduced directly via
  504. the second rule.  Alternatively, nothing-at-all could be reduced into
  505. a `sequence' via the first rule, and this could be combined with the
  506. `word' using the third rule.
  507.  
  508. You might think that this is a distinction without a difference,
  509. because it does not change whether any particular input is valid or
  510. not.  But it does affect which actions are run.  One parsing order
  511. runs the second rule's action; the other runs the first rule's action
  512. and the third rule's action.  In this example, the output of the
  513. program changes.
  514.  
  515. Bison resolves a reduce/reduce conflict by choosing to use the rule
  516. that appears first in the grammar, but it is very risky to rely on
  517. this.  Every reduce/reduce conflict must be studied and usually
  518. eliminated.  Here is the proper way to define `sequence':
  519.  
  520.      sequence: /* empty */
  521.                      { printf ("empty sequence\n"); }
  522.              | sequence word
  523.                      { printf ("added word %s\n", $2); }
  524.              ;
  525.  
  526. Here is another common error that yields a reduce/reduce conflict:
  527.  
  528.      sequence: /* empty */
  529.              | sequence words
  530.              | sequence redirects
  531.              ;
  532.      
  533.      words:    /* empty */
  534.              | words word
  535.              ;
  536.      
  537.      redirects:/* empty */
  538.              | redirects redirect
  539.              ;
  540.  
  541. The intention here is to define a sequence which can contain either
  542. `word' or `redirect' groupings.  The individual definitions of
  543. `sequence', `words' and `redirects' are error-free, but the three
  544. together make a subtle ambiguity: even an empty input can be parsed
  545. in infinitely many ways!
  546.  
  547. Consider: nothing-at-all could be a `words'.  Or it could be two
  548. `words' in a row, or three, or any number.  It could equally well be
  549. a `redirects', or two, or any number.  Or it could be a `words'
  550. followed by three `redirects' and another `words'.  And so on.
  551.  
  552. Here are two ways to correct these rules.  First, to make it a single
  553. level of sequence:
  554.  
  555.      sequence: /* empty */
  556.              | sequence word
  557.              | sequence redirect
  558.              ;
  559.  
  560. Second, to prevent either a `words' or a `redirects' from being empty:
  561.  
  562.      sequence: /* empty */
  563.              | sequence words
  564.              | sequence redirects
  565.              ;
  566.      
  567.      words:    word
  568.              | words word
  569.              ;
  570.      
  571.      redirects:redirect
  572.              | redirects redirect
  573.              ;
  574.  
  575.  
  576.  
  577. File: bison.info,  Node: Error Recovery,  Next: Debugging,  Prev: Algorithm,  Up: Top
  578.  
  579. Error Recovery
  580. **************
  581.  
  582. It is not usually acceptable to have the program terminate on a parse
  583. error.  For example, a compiler should recover sufficiently to parse
  584. the rest of the input file and check it for errors; a calculator
  585. should accept another expression.
  586.  
  587. In a simple interactive command parser where each input is one line,
  588. it may be sufficient to allow `yyparse' to return 1 on error and have
  589. the caller ignore the rest of the input line when that happens (and
  590. then call `yyparse' again).  But this is inadequate for a compiler,
  591. because it forgets all the syntactic context leading up to the error.
  592. A syntax error deep within a function in the compiler input should
  593. not cause the compiler to treat the following line like the beginning
  594. of a source file.
  595.  
  596. You can define how to recover from a syntax error by writing rules to
  597. recognize the special token `error'.  This is a terminal symbol that
  598. is always defined (you need not declare it) and reserved for error
  599. handling.  The Bison parser generates an `error' token whenever a
  600. syntax error happens; if you have provided a rule to recognize this
  601. token in the current context, the parse can continue.  For example:
  602.  
  603.      stmnts:  /* empty string */
  604.              | stmnts '\n'
  605.              | stmnts exp '\n'
  606.              | stmnts error '\n'
  607.  
  608. The fourth rule in this example says that an error followed by a
  609. newline makes a valid addition to any `stmnts'.
  610.  
  611. What happens if a syntax error occurs in the middle of an `exp'?  The
  612. error recovery rule, interpreted strictly, applies to the precise
  613. sequence of a `stmnts', an `error' and a newline.  If an error occurs
  614. in the middle of an `exp', there will probably be some additional
  615. tokens and subexpressions on the stack after the last `stmnts', and
  616. there will be tokens to read before the next newline.  So the rule is
  617. not applicable in the ordinary way.
  618.  
  619. But Bison can force the situation to fit the rule, by discarding part
  620. of the semantic context and part of the input.  First it discards
  621. states and objects from the stack until it gets back to a state in
  622. which the `error' token is acceptable.  (This means that the
  623. subexpressions already parsed are discarded, back to the last
  624. complete `stmnts'.)  At this point the `error' token can be shifted. 
  625. Then, if the old look-ahead token is not acceptable to be shifted
  626. next, the parser reads tokens and discards them until it finds a
  627. token which is acceptable.  In this example, Bison reads and discards
  628. input until the next newline so that the fourth rule can apply.
  629.  
  630. The choice of error rules in the grammar is a choice of strategies
  631. for error recovery.  A simple and useful strategy is simply to skip
  632. the rest of the current input line or current statement if an error
  633. is detected:
  634.  
  635.      stmnt: error ';'  /* on error, skip until ';' is read */
  636.  
  637. It is also useful to recover to the matching close-delimiter of an
  638. opening-delimiter that has already been parsed.  Otherwise the
  639. close-delimiter will probably appear to be unmatched, and generate
  640. another, spurious error message:
  641.  
  642.      primary:  '(' expr ')'
  643.              | '(' error ')'
  644.              ...
  645.              ;
  646.  
  647. Error recovery strategies are necessarily guesses.  When they guess
  648. wrong, one syntax error often leads to another.  In the above
  649. example, the error recovery rule guesses that an error is due to bad
  650. input within one `stmnt'.  Suppose that instead a spurious semicolon
  651. is inserted in the middle of a valid `stmnt'.  After the error
  652. recovery rule recovers from the first error, another syntax error
  653. will be found straightaway, since the text following the spurious
  654. semicolon is also an invalid `stmnt'.
  655.  
  656. To prevent an outpouring of error messages, the parser will output no
  657. error message for another syntax error that happens shortly after the
  658. first; only after three consecutive input tokens have been
  659. successfully shifted will error messages resume.
  660.  
  661. Note that rules which accept the `error' token may have actions, just
  662. as any other rules can.
  663.  
  664. You can make error messages resume immediately by using the macro
  665. `yyerrok' in an action.  If you do this in the error rule's action,
  666. no error messages will be suppressed.  This macro requires no
  667. arguments; `yyerrok;' is a valid C statement.
  668.  
  669. The previous look-ahead token is reanalyzed immediately after an
  670. error.  If this is unacceptable, then the macro `yyclearin' may be
  671. used to clear this token.  Write the statement `yyclearin;' in the
  672. error rule's action.
  673.  
  674. For example, suppose that on a parse error, an error handling routine
  675. is called that advances the input stream to some point where parsing
  676. should once again commence.  The next symbol returned by the lexical
  677. scanner is probably correct.  The previous look-ahead token ought to
  678. be discarded with `yyclearin;'.
  679.  
  680.  
  681.  
  682. File: bison.info,  Node: Debugging,  Next: Invocation,  Prev: Error Recovery,  Up: Top
  683.  
  684. Debugging Your Parser
  685. *********************
  686.  
  687. If a Bison grammar compiles properly but doesn't do what you want
  688. when it runs, the `yydebug' parser-trace feature can help you figure
  689. out why.
  690.  
  691. To enable compilation of trace facilities, you must define the macro
  692. `YYDEBUG' when you compile the parser.  You could use `-DYYDEBUG' as
  693. a compiler option or you could put `#define YYDEBUG' in the C
  694. declarations section of the grammar file (*note C Declarations::.). 
  695. Alternatively, use the `-t' option when you run Bison (*note
  696. Invocation::.).  I always define `YYDEBUG' so that debugging is
  697. always possible.
  698.  
  699. The trace facility uses `stderr', so you must add
  700. `#include <stdio.h>' to the C declarations section unless it is
  701. already there.
  702.  
  703. Once you have compiled the program with trace facilities, the way to
  704. request a trace is to store a nonzero value in the variable `yydebug'.
  705. You can do this by making the C code do it (in `main', perhaps), or
  706. you can alter the value with a C debugger.
  707.  
  708. Each step taken by the parser when `yydebug' is nonzero produces a
  709. line or two of trace information, written on `stderr'.  The trace
  710. messages tell you these things:
  711.  
  712.    * Each time the parser calls `yylex', what kind of token was read.
  713.  
  714.    * Each time a token is shifted, the depth and complete contents of
  715.      the state stack (*note Parser States::.).
  716.  
  717.    * Each time a rule is reduced, which rule it is, and the complete
  718.      contents of the state stack afterward.
  719.  
  720. To make sense of this information, it helps to refer to the listing
  721. file produced by the Bison `-v' option (*note Invocation::.).  This
  722. file shows the meaning of each state in terms of positions in various
  723. rules, and also what each state will do with each possible input
  724. token.  As you read the successive trace messages, you can see that
  725. the parser is functioning according to its specification in the
  726. listing file.  Eventually you will arrive at the place where
  727. something undesirable happens, and you will see which parts of the
  728. grammar are to blame.
  729.  
  730. The parser file is a C program and you can use C debuggers on it, but
  731. it's not easy to interpret what it is doing.  The parser function is
  732. a finite-state machine interpreter, and aside from the actions it
  733. executes the same code over and over.  Only the values of variables
  734. show where in the grammar it is working.
  735.  
  736.  
  737.  
  738. File: bison.info,  Node: Invocation,  Next: Table of Symbols,  Prev: Debugging,  Up: Top
  739.  
  740. Invocation of Bison; Command Options
  741. ************************************
  742.  
  743. The usual way to invoke Bison is as follows:
  744.  
  745.      bison INFILE
  746.  
  747. Here INFILE is the grammar file name, which usually ends in `.y'. 
  748. The parser file's name is made by replacing the `.y' with `.tab.c'. 
  749. Thus, `bison foo.y' outputs `foo.tab.c'.
  750.  
  751. These options can be used with Bison:
  752.  
  753. `-d'
  754.      Write an extra output file containing macro definitions for the
  755.      token type names defined in the grammar and the semantic value
  756.      type `YYSTYPE', as well as a few `extern' variable declarations.
  757.  
  758.      If the parser output file is named `NAME.c' then this file is
  759.      named `NAME.h'.
  760.  
  761.      This output file is essential if you wish to put the definition
  762.      of `yylex' in a separate source file, because `yylex' needs to
  763.      be able to refer to token type codes and the variable `yylval'. 
  764.      *Note Lexical::.
  765.  
  766. `-l'
  767.      Don't put any `#line' preprocessor commands in the parser file. 
  768.      Ordinarily Bison puts them in the parser file so that the C
  769.      compiler and debuggers will associate errors with your source
  770.      file, the grammar file.  This option causes them to associate
  771.      errors with the parser file, treating it an independent source
  772.      file in its own right.
  773.  
  774. `-o OUTFILE'
  775.      Specify the name OUTFILE for the parser file.
  776.  
  777.      The other output files' names are constructed from OUTFILE as
  778.      described under the `-v' and `-d' switches.
  779.  
  780. `-t'
  781.      Output a definition of the macro `YYDEBUG' into the parser file,
  782.      so that the debugging facilities are compiled.  *Note Debugging::.
  783.  
  784. `-v'
  785.      Write an extra output file containing verbose descriptions of
  786.      the parser states and what is done for each type of look-ahead
  787.      token in that state.
  788.  
  789.      This file also describes all the conflicts, both those resolved
  790.      by operator precedence and the unresolved ones.
  791.  
  792.      The file's name is made by removing `.tab.c' or `.c' from the
  793.      parser output file name, and adding `.output' instead.
  794.  
  795.      Therefore, if the input file is `foo.y', then the parser file is
  796.      called `foo.tab.c' by default.  As a consequence, the verbose
  797.      output file is called `foo.output'.
  798.  
  799. `-y'
  800.      Equivalent to `-o y.tab.c'; the parser output file is called
  801.      `y.tab.c', and the other outputs are called `y.output' and
  802.      `y.tab.h'.  The purpose of this switch is to imitate Yacc's
  803.      output file name conventions.
  804.  
  805.      If the Bison utility is given the file name `yacc', then it
  806.      assumes the `-y' option automatically.  Thus, Bison can
  807.      substitute precisely for Yacc.
  808.  
  809.  
  810.  
  811. File: bison.info,  Node: Table of Symbols,  Next: Glossary,  Prev: Invocation,  Up: Top
  812.  
  813. Table of Bison Symbols
  814. **********************
  815.  
  816. `error'
  817.      A token name reserved for error recovery.  This token may be
  818.      used in grammar rules so as to allow the Bison parser to
  819.      recognize an error in the grammar without halting the process. 
  820.      In effect, a sentence containing an error may be recognized as
  821.      valid.  On a parse error, the token `error' becomes the current
  822.      look-ahead token.  Actions corresponding to `error' are then
  823.      executed, and the look-ahead token is reset to the token that
  824.      originally caused the violation.  *Note Error Recovery::.
  825.  
  826. `YYACCEPT'
  827.      Pretend that a complete utterance of the language has been read,
  828.      by making `yyparse' return 0 immediately.  *Note Parser
  829.      Function::.
  830.  
  831. `YYERROR'
  832.      Pretend that an unrecoverable syntax error has occurred, by
  833.      making `yyparse' return 1 immediately.  The error reporting
  834.      function `yyerror' is not called.  *Note Parser Function::.
  835.  
  836. `YYFAIL'
  837.      Pretend that a syntax error has just been detected: call
  838.      `yyerror' and then perform normal error recovery if possible
  839.      (*note Error Recovery::.) or (if recovery is not possible) make
  840.      `yyparse' return nonzero.  *Note Error Recovery::.
  841.  
  842. `YYSTYPE'
  843.      Data type of semantic values; `int' by default.  *Note Value
  844.      Type::.
  845.  
  846. `yychar'
  847.      External integer variable that contains the integer value of the
  848.      current look-ahead token.  Error-recovery rule actions may
  849.      examine this variable.  *Note Action Features::.
  850.  
  851. `yyclearin'
  852.      Macro used in error-recovery rule actions.  It clears the
  853.      previous look-ahead token.  *Note Error Recovery::.
  854.  
  855. `yydebug'
  856.      External integer variable set to zero by default.  If `yydebug'
  857.      is given a nonzero value, the parser will output information on
  858.      input symbols and parser action.  *Note Debugging::.
  859.  
  860. `yyerrok'
  861.      Macro to cause parser to recover immediately to its normal mode
  862.      after a parse error.  *Note Error Recovery::.
  863.  
  864. `yyerror'
  865.      User-supplied function to be called by `yyparse' on error.  The
  866.      function receives one argument, a pointer to a character string
  867.      containing an error message.  *Note Error Reporting::.
  868.  
  869. `yylex'
  870.      User-supplied lexical analyzer function, called with no
  871.      arguments to get the next token.  *Note Lexical::.
  872.  
  873. `yylval'
  874.      External variable in which `yylex' should place the semantic
  875.      value associated with a token.  *Note Lexical::.
  876.  
  877. `yylloc'
  878.      External variable in which `yylex' should place the line and
  879.      column numbers associated with a token.  This is needed only if
  880.      the `@' feature is used in the grammar actions.  *Note Lexical::.
  881.  
  882. `yyparse'
  883.      The parser function produced by Bison; call this function to
  884.      start parsing.  *Note Parser Function::.
  885.  
  886. `%left'
  887.      Bison declaration to assign left associativity to token(s). 
  888.      *Note Precedence Decl::.
  889.  
  890. `%nonassoc'
  891.      Bison declaration to assign nonassociativity to token(s).  *Note
  892.      Precedence Decl::.
  893.  
  894. `%prec'
  895.      Bison declaration to assign a precedence to a specific rule. 
  896.      *Note Contextual Precedence::.
  897.  
  898. `%pure_parser'
  899.      Bison declaration to request a pure (reentrant) parser.  *Note
  900.      Pure Decl::.
  901.  
  902. `%right'
  903.      Bison declaration to assign right associativity to token(s). 
  904.      *Note Precedence Decl::.
  905.  
  906. `%start'
  907.      Bison declaration to specify the start symbol.  *Note Start
  908.      Decl::.
  909.  
  910. `%token'
  911.      Bison declaration to declare token(s) without specifying
  912.      precedence.  *Note Token Decl::.
  913.  
  914. `%type'
  915.      Bison declaration to declare nonterminals.  *Note Type Decl::.
  916.  
  917. `%union'
  918.      Bison declaration to specify several possible data types for
  919.      semantic values.  *Note Union Decl::.
  920.  
  921. These are the punctuation and delimiters used in Bison input:
  922.  
  923. `%%'
  924.      Delimiter used to separate the grammar rule section from the
  925.      Bison declarations section or the additional C code section. 
  926.      *Note Grammar Layout::.
  927.  
  928. `%{ %}'
  929.      All code listed between `%{' and `%}' is copied directly to the
  930.      output file uninterpreted.  Such code forms the ``C
  931.      declarations'' section of the input file.  *Note Grammar
  932.      Outline::.
  933.  
  934. `/*...*/'
  935.      Comment delimiters, as in C.
  936.  
  937. `:'
  938.      Separates a rule's result from its components.  *Note Rules::.
  939.  
  940. `;'
  941.      Terminates a rule.  *Note Rules::.
  942.  
  943. `|'
  944.      Separates alternate rules for the same result nonterminal. 
  945.      *Note Rules::.
  946.  
  947.  
  948.  
  949. File: bison.info,  Node: Glossary,  Next: Index,  Prev: Table of Symbols,  Up: top
  950.  
  951. Glossary
  952. ********
  953.  
  954. Backus-Naur Form (BNF)
  955.      Formal method of specifying context-free grammars.  BNF was
  956.      first used in the ``ALGOL-60'' report, 1963.  *Note Language and
  957.      Grammar::.
  958.  
  959. Context-free grammars
  960.      Grammars specified as rules that can be applied regardless of
  961.      context.  Thus, if there is a rule which says that an integer
  962.      can be used as an expression, integers are allowed *anywhere* an
  963.      expression is permitted.  *Note Language and Grammar::.
  964.  
  965. Dynamic allocation
  966.      Allocation of memory that occurs during execution, rather than
  967.      at compile time or on entry to a function.
  968.  
  969. Empty string
  970.      Analogous to the empty set in set theory, the empty string is a
  971.      character string of length zero.
  972.  
  973. Finite-state stack machine
  974.      A ``machine'' that has discrete states in which it is said to
  975.      exist at each instant in time.  As input to the machine is
  976.      processed, the machine moves from state to state as specified by
  977.      the logic of the machine.  In the case of the parser, the input
  978.      is the language being parsed, and the states correspond to
  979.      various stages in the grammar rules.  *Note Algorithm::.
  980.  
  981. Grouping
  982.      A language construct that is (in general) grammatically
  983.      divisible; for example, `expression' or `declaration' in C. 
  984.      *Note Language and Grammar::.
  985.  
  986. Infix operator
  987.      An arithmetic operator that is placed between the operands on
  988.      which it performs some operation.
  989.  
  990. Input stream
  991.      A continuous flow of data between devices or programs.
  992.  
  993. Language construct
  994.      One of the typical usage schemas of the language.  For example,
  995.      one of the constructs of the C language is the `if' statement. 
  996.      *Note Language and Grammar::.
  997.  
  998. Left associativity
  999.      Operators having left associativity are analyzed from left to
  1000.      right: `a+b+c' first computes `a+b' and then combines with `c'. 
  1001.      *Note Precedence::.
  1002.  
  1003. Left recursion
  1004.      A rule whose result symbol is also its first component symbol;
  1005.      for example, `expseq1 : expseq1 ',' exp;'.  *Note Recursion::.
  1006.  
  1007. Left-to-right parsing
  1008.      Parsing a sentence of a language by analyzing it token by token
  1009.      from left to right.  *Note Algorithm::.
  1010.  
  1011. Lexical analyzer (scanner)
  1012.      A function that reads an input stream and returns tokens one by
  1013.      one.
  1014.  
  1015. Look-ahead token
  1016.      A token already read but not yet shifted.  *Note Look-Ahead::.
  1017.  
  1018. Nonterminal symbol
  1019.      A grammar symbol standing for a grammatical construct that can
  1020.      be expressed through rules in terms of smaller constructs; in
  1021.      other words, a construct that is not a token.  *Note Symbols::.
  1022.  
  1023. Parse error
  1024.      An error encountered during parsing of an input stream due to
  1025.      invalid syntax.  *Note Error Recovery::.
  1026.  
  1027. Parser
  1028.      A function that recognizes valid sentences of a language by
  1029.      analyzing the syntax structure of a set of tokens passed to it
  1030.      from a lexical analyzer.
  1031.  
  1032. Postfix operator
  1033.      An arithmetic operator that is placed after the operands upon
  1034.      which it performs some operation.
  1035.  
  1036. Reduction
  1037.      Replacing a string of nonterminals and/or terminals with a
  1038.      single nonterminal, according to a grammar rule.  *Note
  1039.      Algorithm::.
  1040.  
  1041. Reverse polish notation
  1042.      A language in which all operators are postfix operators.
  1043.  
  1044. Right recursion
  1045.      A rule whose result symbol is also its last component symbol;
  1046.      for example, `expseq1: exp ',' expseq1;'.  *Note Recursion::.
  1047.  
  1048. Semantics
  1049.      In computer languages the semantics are specified by the actions
  1050.      taken for each instance of the language, i.e., the meaning of
  1051.      each statement.  *Note Semantics::.
  1052.  
  1053. Shift
  1054.      A parser is said to shift when it makes the choice of analyzing
  1055.      further input from the stream rather than reducing immediately
  1056.      some already-recognized rule.  *Note Algorithm::.
  1057.  
  1058. Single-character literal
  1059.      A single character that is recognized and interpreted as is. 
  1060.      *Note Grammar in Bison::.
  1061.  
  1062. Start symbol
  1063.      The nonterminal symbol that stands for a complete valid
  1064.      utterance in the language being parsed.  The start symbol is
  1065.      usually listed as the first nonterminal symbol in a language
  1066.      specification.  *Note Start Decl::.
  1067.  
  1068. Symbol table
  1069.      A data structure where symbol names and associated data are
  1070.      stored during parsing to allow for recognition and use of
  1071.      existing information in repeated uses of a symbol.  *Note
  1072.      Multi-function Calc::.
  1073.  
  1074. Token
  1075.      A basic, grammatically indivisible unit of a language.  The
  1076.      symbol that describes a token in the grammar is a terminal symbol.
  1077.      The input of the Bison parser is a stream of tokens which comes
  1078.      from the lexical analyzer.  *Note Symbols::.
  1079.  
  1080. Terminal symbol
  1081.      A grammar symbol that has no rules in the grammar and therefore
  1082.      is grammatically indivisible.  The piece of text it represents
  1083.      is a token.  *Note Language and Grammar::.
  1084.  
  1085.  
  1086.  
  1087. File: bison.info,  Node: Index,  Prev: Glossary,  Up: top
  1088.  
  1089. Index
  1090. *****
  1091.  
  1092. * Menu:
  1093.  
  1094. * $$: Actions.
  1095. * $N: Actions.
  1096. * %expect: Expect Decl.
  1097. * %left: Using Precedence.
  1098. * %nonassoc: Using Precedence.
  1099. * %prec: Contextual Precedence.
  1100. * %pure_parser: Pure Decl.
  1101. * %right: Using Precedence.
  1102. * %start: Start Decl.
  1103. * %token: Token Decl.
  1104. * %type: Type Decl.
  1105. * %union: Union Decl.
  1106. * @N: Action Features.
  1107. * `calc': Infix Calc.
  1108. * `else', dangling: Shift/Reduce.
  1109. * `mfcalc': Multi-function Calc.
  1110. * `rpcalc': RPN Calc.
  1111. * BNF: Language and Grammar.
  1112. * Backus-Naur form: Language and Grammar.
  1113. * Bison declaration summary: Decl Summary.
  1114. * Bison declarations: Declarations.
  1115. * Bison declarations section (introduction): Bison Declarations.
  1116. * Bison grammar: Grammar in Bison.
  1117. * Bison invocation: Invocation.
  1118. * Bison parser: Bison Parser.
  1119. * Bison symbols, table of: Table of Symbols.
  1120. * Bison utility: Bison Parser.
  1121. * C code, section for additional: C Code.
  1122. * C declarations section: C Declarations.
  1123. * C-language interface: Interface.
  1124. * YYABORT: Parser Function.
  1125. * YYACCEPT: Parser Function.
  1126. * YYDEBUG: Debugging.
  1127. * action: Actions.
  1128. * action data types: Action Types.
  1129. * action features summary: Action Features.
  1130. * actions in mid-rule: Mid-Rule Actions.
  1131. * actions, semantic: Semantic Actions.
  1132. * additional C code section: C Code.
  1133. * algorithm of parser: Algorithm.
  1134. * associativity: Why Precedence.
  1135. * calculator, infix notation: Infix Calc.
  1136. * calculator, multi-function: Multi-function Calc.
  1137. * calculator, simple: RPN Calc.
  1138. * character token: Symbols.
  1139. * compiling the parser: Rpcalc Compile.
  1140. * conflicts: Shift/Reduce.
  1141. * conflicts, preventing warnings of: Expect Decl.
  1142. * context-dependent precedence: Contextual Precedence.
  1143. * context-free grammar: Language and Grammar.
  1144. * controlling function: Rpcalc Main.
  1145. * dangling `else': Shift/Reduce.
  1146. * data types in actions: Action Types.
  1147. * data types of semantic values: Value Type.
  1148. * debugging: Debugging.
  1149. * declaration summary: Decl Summary.
  1150. * declarations section, Bison (introduction): Bison Declarations.
  1151. * declarations, Bison: Declarations.
  1152. * declarations, C: C Declarations.
  1153. * declaring operator precedence: Precedence Decl.
  1154. * declaring the start-symbol: Start Decl.
  1155. * declaring token type names: Token Decl.
  1156. * declaring value types: Union Decl.
  1157. * declaring value types, nonterminals: Type Decl.
  1158. * error: Error Recovery.
  1159. * error recovery: Error Recovery.
  1160. * error recovery, simple: Simple Error Recovery.
  1161. * error reporting function: Error Reporting.
  1162. * error reporting routine: Rpcalc Error.
  1163. * examples, simple: Examples.
  1164. * exercises: Exercises.
  1165. * finite-state machine: Parser States.
  1166. * formal grammar: Grammar in Bison.
  1167. * glossary: Glossary.
  1168. * grammar file: Grammar Layout.
  1169. * grammar rule syntax: Rules.
  1170. * grammar rules section: Grammar Rules.
  1171. * grammar, context-free: Language and Grammar.
  1172. * grouping, syntactic: Language and Grammar.
  1173. * infix notation calculator: Infix Calc.
  1174. * interface: Interface.
  1175. * introduction: Introduction.
  1176. * invoking Bison: Invocation.
  1177. * language semantics: Semantics.
  1178. * layout of Bison grammar: Grammar Layout.
  1179. * left recursion: Recursion.
  1180. * lexical analyzer: Lexical.
  1181. * lexical analyzer, purpose: Bison Parser.
  1182. * lexical analyzer, writing: Rpcalc Lexer.
  1183. * literal token: Symbols.
  1184. * look-ahead token: Look-Ahead.
  1185. * main function in simple example: Rpcalc Main.
  1186. * mid-rule actions: Mid-Rule Actions.
  1187. * multi-function calculator: Multi-function Calc.
  1188. * mutual recursion: Recursion.
  1189. * nonterminal symbol: Symbols.
  1190. * operator precedence: Precedence.
  1191. * operator precedence, declaring: Precedence Decl.
  1192. * options for Bison invocation: Invocation.
  1193. * parser: Bison Parser.
  1194. * parser stack: Algorithm.
  1195. * parser state: Parser States.
  1196. * polish notation calculator: RPN Calc.
  1197. * precedence of operators: Precedence.
  1198. * preventing warnings about conflicts: Expect Decl.
  1199. * pure parser: Pure Decl.
  1200. * recovery from errors: Error Recovery.
  1201. * recursive rule: Recursion.
  1202. * reduce/reduce conflict: Reduce/Reduce.
  1203. * reduction: Algorithm.
  1204. * reentrant parser: Pure Decl.
  1205. * reverse polish notation: RPN Calc.
  1206. * right recursion: Recursion.
  1207. * rule syntax: Rules.
  1208. * rules section for grammar: Grammar Rules.
  1209. * running Bison (introduction): Rpcalc Gen.
  1210. * semantic actions: Semantic Actions.
  1211. * semantic value: Semantic Values.
  1212. * semantic value type: Value Type.
  1213. * semantics of the language: Semantics.
  1214. * shift/reduce conflicts: Shift/Reduce.
  1215. * shifting: Algorithm.
  1216. * simple examples: Examples.
  1217. * single-character literal: Symbols.
  1218. * stack, parser: Algorithm.
  1219. * stages in using Bison: Stages.
  1220. * start symbol: Language and Grammar.
  1221. * start-symbol, declaring: Start Decl.
  1222. * state (of parser): Parser States.
  1223. * summary, Bison declaration: Decl Summary.
  1224. * summary, action features: Action Features.
  1225. * symbol: Symbols.
  1226. * symbol table example: Mfcalc Symtab.
  1227. * symbols (abstract): Language and Grammar.
  1228. * symbols in Bison, table of: Table of Symbols.
  1229. * syntactic grouping: Language and Grammar.
  1230. * syntax of grammar rules: Rules.
  1231. * terminal symbol: Symbols.
  1232. * token: Language and Grammar.
  1233. * token type: Symbols.
  1234. * token type names, declaring: Token Decl.
  1235. * tracing the parser: Debugging.
  1236. * unary operator precedence: Contextual Precedence.
  1237. * value type, semantic: Value Type.
  1238. * value types, declaring: Union Decl.
  1239. * value types, nonterminals, declaring: Type Decl.
  1240. * warnings, preventing: Expect Decl.
  1241. * writing a lexical analyzer: Rpcalc Lexer.
  1242. * yychar: Look-Ahead.
  1243. * yyclearin: Error Recovery.
  1244. * yydebug: Debugging.
  1245. * yyerrok: Error Recovery.
  1246. * yyerror: Error Reporting.
  1247. * yyerror: Rpcalc Error.
  1248. * yylex: Lexical.
  1249. * yylloc: Lexical.
  1250. * yylval: Lexical.
  1251. * yynerr: Error Reporting.
  1252. * yyparse: Parser Function.
  1253. * |: Rules.
  1254.  
  1255.  
  1256.  
  1257. Tag Table:
  1258. Node: Top1084
  1259. Node: Introduction2071
  1260. Node: Conditions3145
  1261. Node: Copying4998
  1262. Node: Concepts12368
  1263. Node: Language and Grammar13402
  1264. Node: Grammar in Bison17868
  1265. Node: Semantic Values19590
  1266. Node: Semantic Actions21661
  1267. Node: Bison Parser22838
  1268. Node: Stages25073
  1269. Node: Grammar Layout26290
  1270. Node: Examples27532
  1271. Node: RPN Calc28611
  1272. Node: Rpcalc Decls29787
  1273. Node: Rpcalc Rules31289
  1274. Node: Rpcalc Input33019
  1275. Node: Rpcalc Line34475
  1276. Node: Rpcalc Expr35580
  1277. Node: Rpcalc Lexer37531
  1278. Node: Rpcalc Main40045
  1279. Node: Rpcalc Error40421
  1280. Node: Rpcalc Gen41394
  1281. Node: Rpcalc Compile42502
  1282. Node: Infix Calc43374
  1283. Node: Simple Error Recovery45933
  1284. Node: Multi-function Calc47808
  1285. Node: Mfcalc Decl49346
  1286. Node: Mfcalc Rules51298
  1287. Node: Mfcalc Symtab52676
  1288. Node: Exercises58823
  1289. Node: Grammar File59331
  1290. Node: Grammar Outline60025
  1291. Node: C Declarations60782
  1292. Node: Bison Declarations61383
  1293. Node: Grammar Rules61775
  1294. Node: C Code62207
  1295. Node: Symbols63100
  1296. Node: Rules66683
  1297. Node: Recursion68305
  1298. Node: Semantics69982
  1299. Node: Value Type71071
  1300. Node: Multiple Types71705
  1301. Node: Actions72659
  1302. Node: Action Types75022
  1303. Node: Mid-Rule Actions76317
  1304. Node: Declarations81594
  1305. Node: Token Decl82812
  1306. Node: Precedence Decl84116
  1307. Node: Union Decl85663
  1308. Node: Type Decl86500
  1309. Node: Expect Decl87229
  1310. Node: Start Decl88751
  1311. Node: Pure Decl89148
  1312. Node: Decl Summary90244
  1313. Node: Interface91445
  1314. Node: Parser Function92280
  1315. Node: Lexical93123
  1316. Node: Error Reporting97392
  1317. Node: Action Features98415
  1318. Node: Algorithm100822
  1319. Node: Look-Ahead102942
  1320. Node: Shift/Reduce105044
  1321. Node: Precedence107432
  1322. Node: Why Precedence108086
  1323. Node: Using Precedence109938
  1324. Node: Precedence Examples110899
  1325. Node: How Precedence111598
  1326. Node: Contextual Precedence112699
  1327. Node: Parser States114487
  1328. Node: Reduce/Reduce115721
  1329. Node: Error Recovery118871
  1330. Node: Debugging123710
  1331. Node: Invocation126123
  1332. Node: Table of Symbols128802
  1333. Node: Glossary133296
  1334. Node: Index138266
  1335.