/[bison]/bison/doc/bison.info-3
ViewVC logotype

Diff of /bison/doc/bison.info-3

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.8 by akim, Wed Aug 15 08:37:52 2001 UTC revision 1.8.2.1 by akim, Wed Aug 29 12:16:04 2001 UTC
# Line 29  included in translations approved by the Line 29  included in translations approved by the
29  instead of in the original English.  instead of in the original English.
30    
31    
32    File: bison.info,  Node: Value Type,  Next: Multiple Types,  Up: Semantics
33    
34    Data Types of Semantic Values
35    -----------------------------
36    
37       In a simple program it may be sufficient to use the same data type
38    for the semantic values of all language constructs.  This was true in
39    the RPN and infix calculator examples (*note Reverse Polish Notation
40    Calculator: RPN Calc.).
41    
42       Bison's default is to use type `int' for all semantic values.  To
43    specify some other type, define `YYSTYPE' as a macro, like this:
44    
45         #define YYSTYPE double
46    
47    This macro definition must go in the C declarations section of the
48    grammar file (*note Outline of a Bison Grammar: Grammar Outline.).
49    
50    
51    File: bison.info,  Node: Multiple Types,  Next: Actions,  Prev: Value Type,  Up: Semantics
52    
53    More Than One Value Type
54    ------------------------
55    
56       In most programs, you will need different data types for different
57    kinds of tokens and groupings.  For example, a numeric constant may
58    need type `int' or `long', while a string constant needs type `char *',
59    and an identifier might need a pointer to an entry in the symbol table.
60    
61       To use more than one data type for semantic values in one parser,
62    Bison requires you to do two things:
63    
64       * Specify the entire collection of possible data types, with the
65         `%union' Bison declaration (*note The Collection of Value Types:
66         Union Decl.).
67    
68       * Choose one of those types for each symbol (terminal or
69         nonterminal) for which semantic values are used.  This is done for
70         tokens with the `%token' Bison declaration (*note Token Type
71         Names: Token Decl.)  and for groupings with the `%type' Bison
72         declaration (*note Nonterminal Symbols: Type Decl.).
73    
74    
75    File: bison.info,  Node: Actions,  Next: Action Types,  Prev: Multiple Types,  Up: Semantics
76    
77    Actions
78    -------
79    
80       An action accompanies a syntactic rule and contains C code to be
81    executed each time an instance of that rule is recognized.  The task of
82    most actions is to compute a semantic value for the grouping built by
83    the rule from the semantic values associated with tokens or smaller
84    groupings.
85    
86       An action consists of C statements surrounded by braces, much like a
87    compound statement in C.  It can be placed at any position in the rule;
88    it is executed at that position.  Most rules have just one action at
89    the end of the rule, following all the components.  Actions in the
90    middle of a rule are tricky and used only for special purposes (*note
91    Actions in Mid-Rule: Mid-Rule Actions.).
92    
93       The C code in an action can refer to the semantic values of the
94    components matched by the rule with the construct `$N', which stands for
95    the value of the Nth component.  The semantic value for the grouping
96    being constructed is `$$'.  (Bison translates both of these constructs
97    into array element references when it copies the actions into the parser
98    file.)
99    
100       Here is a typical example:
101    
102         exp:    ...
103                 | exp '+' exp
104                     { $$ = $1 + $3; }
105    
106    This rule constructs an `exp' from two smaller `exp' groupings
107    connected by a plus-sign token.  In the action, `$1' and `$3' refer to
108    the semantic values of the two component `exp' groupings, which are the
109    first and third symbols on the right hand side of the rule.  The sum is
110    stored into `$$' so that it becomes the semantic value of the
111    addition-expression just recognized by the rule.  If there were a
112    useful semantic value associated with the `+' token, it could be
113    referred to as `$2'.
114    
115       If you don't specify an action for a rule, Bison supplies a default:
116    `$$ = $1'.  Thus, the value of the first symbol in the rule becomes the
117    value of the whole rule.  Of course, the default rule is valid only if
118    the two data types match.  There is no meaningful default action for an
119    empty rule; every empty rule must have an explicit action unless the
120    rule's value does not matter.
121    
122       `$N' with N zero or negative is allowed for reference to tokens and
123    groupings on the stack _before_ those that match the current rule.
124    This is a very risky practice, and to use it reliably you must be
125    certain of the context in which the rule is applied.  Here is a case in
126    which you can use this reliably:
127    
128         foo:      expr bar '+' expr  { ... }
129                 | expr bar '-' expr  { ... }
130                 ;
131        
132         bar:      /* empty */
133                 { previous_expr = $0; }
134                 ;
135    
136       As long as `bar' is used only in the fashion shown here, `$0' always
137    refers to the `expr' which precedes `bar' in the definition of `foo'.
138    
139    
140    File: bison.info,  Node: Action Types,  Next: Mid-Rule Actions,  Prev: Actions,  Up: Semantics
141    
142    Data Types of Values in Actions
143    -------------------------------
144    
145       If you have chosen a single data type for semantic values, the `$$'
146    and `$N' constructs always have that data type.
147    
148       If you have used `%union' to specify a variety of data types, then
149    you must declare a choice among these types for each terminal or
150    nonterminal symbol that can have a semantic value.  Then each time you
151    use `$$' or `$N', its data type is determined by which symbol it refers
152    to in the rule.  In this example,
153    
154         exp:    ...
155                 | exp '+' exp
156                     { $$ = $1 + $3; }
157    
158    `$1' and `$3' refer to instances of `exp', so they all have the data
159    type declared for the nonterminal symbol `exp'.  If `$2' were used, it
160    would have the data type declared for the terminal symbol `'+'',
161    whatever that might be.
162    
163       Alternatively, you can specify the data type when you refer to the
164    value, by inserting `<TYPE>' after the `$' at the beginning of the
165    reference.  For example, if you have defined types as shown here:
166    
167         %union {
168           int itype;
169           double dtype;
170         }
171    
172    then you can write `$<itype>1' to refer to the first subunit of the
173    rule as an integer, or `$<dtype>1' to refer to it as a double.
174    
175    
176  File: bison.info,  Node: Mid-Rule Actions,  Prev: Action Types,  Up: Semantics  File: bison.info,  Node: Mid-Rule Actions,  Prev: Action Types,  Up: Semantics
177    
178  Actions in Mid-Rule  Actions in Mid-Rule
# Line 1171  useful in actions. Line 1315  useful in actions.
1315       textual position of the Nth component of the current rule.  *Note       textual position of the Nth component of the current rule.  *Note
1316       Tracking Locations: Locations.       Tracking Locations: Locations.
1317    
   
 File: bison.info,  Node: Algorithm,  Next: Error Recovery,  Prev: Interface,  Up: Top  
   
 The Bison Parser Algorithm  
 **************************  
   
    As Bison reads tokens, it pushes them onto a stack along with their  
 semantic values.  The stack is called the "parser stack".  Pushing a  
 token is traditionally called "shifting".  
   
    For example, suppose the infix calculator has read `1 + 5 *', with a  
 `3' to come.  The stack will have four elements, one for each token  
 that was shifted.  
   
    But the stack does not always have an element for each token read.  
 When the last N tokens and groupings shifted match the components of a  
 grammar rule, they can be combined according to that rule.  This is  
 called "reduction".  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.  
   
    For example, if the infix calculator's parser stack contains this:  
   
      1 + 5 * 3  
   
 and the next input token is a newline character, then the last three  
 elements can be reduced to 15 via the rule:  
   
      expr: expr '*' expr;  
   
 Then the stack contains just these three elements:  
   
      1 + 15  
   
 At this point, another reduction can be made, resulting in the single  
 value 16.  Then the newline token can be shifted.  
   
    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 (*note Languages and Context-Free Grammars: Language and  
 Grammar.).  
   
    This kind of parser is known in the literature as a bottom-up parser.  
   
 * Menu:  
   
 * Look-Ahead::        Parser looks one token ahead when deciding what to do.  
 * Shift/Reduce::      Conflicts: when either shifting or reduction is valid.  
 * Precedence::        Operator precedence works by resolving conflicts.  
 * Contextual Precedence::  When an operator's precedence depends on context.  
 * Parser States::     The parser is a finite-state-machine with stack.  
 * Reduce/Reduce::     When two rules are applicable in the same situation.  
 * Mystery Conflicts::  Reduce/reduce conflicts that look unjustified.  
 * Stack Overflow::    What happens when stack gets full.  How to avoid it.  
   
   
 File: bison.info,  Node: Look-Ahead,  Next: Shift/Reduce,  Up: Algorithm  
   
 Look-Ahead Tokens  
 =================  
   
    The Bison parser does _not_ always reduce immediately as soon as the  
 last N 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 "looks ahead" at the next  
 token in order to decide what to do.  
   
    When a token is read, it is not immediately shifted; first it  
 becomes the "look-ahead token", 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.  
   
    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 (`!'), and allow parentheses for grouping.  
   
      expr:     term '+' expr  
              | term  
              ;  
       
      term:     '(' expr ')'  
              | term '!'  
              | NUMBER  
              ;  
   
    Suppose that the tokens `1 + 2' have been read and shifted; what  
 should be done?  If the following token is `)', then the first three  
 tokens must be reduced to form an `expr'.  This is the only valid  
 course, because shifting the `)' would produce a sequence of symbols  
 `term ')'', and no rule allows this.  
   
    If the following token is `!', then it must be shifted immediately so  
 that `2 !' can be reduced to make a `term'.  If instead the parser were  
 to reduce before shifting, `1 + 2' would become an `expr'.  It would  
 then be impossible to shift the `!' because doing so would produce on  
 the stack the sequence of symbols `expr '!''.  No rule allows that  
 sequence.  
   
    The current look-ahead token is stored in the variable `yychar'.  
 *Note Special Features for Use in Actions: Action Features.  
   

Legend:
Removed from v.1.8  
changed lines
  Added in v.1.8.2.1

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26