Next: Empty Rules, Up: Grammar Rules [Contents][Index]
A Bison grammar rule has the following general form:
result: components…;
where result is the nonterminal symbol that this rule describes, and components are various terminal and nonterminal symbols that are put together by this rule (see Symbols, Terminal and Nonterminal).
For example,
exp: exp '+' exp;
says that two groupings of type exp
, with a ‘+’ token in between,
can be combined into a larger grouping of type exp
.
White space in rules is significant only to separate symbols. You can add extra white space as you wish.
Scattered among the components can be actions that determine the semantics of the rule. An action looks like this:
{C statements}
This is an example of braced code, that is, C code surrounded by braces, much like a compound statement in C. Braced code can contain any sequence of C tokens, so long as its braces are balanced. Bison does not check the braced code for correctness directly; it merely copies the code to the parser implementation file, where the C compiler can check it.
Within braced code, the balanced-brace count is not affected by braces within comments, string literals, or character constants, but it is affected by the C digraphs ‘<%’ and ‘%>’ that represent braces. At the top level braced code must be terminated by ‘}’ and not by a digraph. Bison does not look for trigraphs, so if braced code uses trigraphs you should ensure that they do not affect the nesting of braces or the boundaries of comments, string literals, or character constants.
Usually there is only one action and it follows the components. See Actions.
Multiple rules for the same result can be written separately or can be joined with the vertical-bar character ‘|’ as follows:
result: rule1-components… | rule2-components… … ;
They are still considered distinct rules even when joined in this way.
Next: Empty Rules, Up: Grammar Rules [Contents][Index]