1 .\" Copyright (C) Caldera International Inc. 2001-2002. All rights reserved.
3 .\" Redistribution and use in source and binary forms, with or without
4 .\" modification, are permitted provided that the following conditions are
7 .\" Redistributions of source code and documentation must retain the above
8 .\" copyright notice, this list of conditions and the following
11 .\" Redistributions in binary form must reproduce the above copyright
12 .\" notice, this list of conditions and the following disclaimer in the
13 .\" documentation and/or other materials provided with the distribution.
15 .\" All advertising materials mentioning features or use of this software
16 .\" must display the following acknowledgement:
18 .\" This product includes software developed or owned by Caldera
19 .\" International, Inc. Neither the name of Caldera International, Inc.
20 .\" nor the names of other contributors may be used to endorse or promote
21 .\" products derived from this software without specific prior written
24 .\" USE OF THE SOFTWARE PROVIDED FOR UNDER THIS LICENSE BY CALDERA
25 .\" INTERNATIONAL, INC. AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR
26 .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
27 .\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
28 .\" DISCLAIMED. IN NO EVENT SHALL CALDERA INTERNATIONAL, INC. BE LIABLE
29 .\" FOR ANY DIRECT, INDIRECT INCIDENTAL, SPECIAL, EXEMPLARY, OR
30 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
31 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
32 .\" BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
33 .\" WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
34 .\" OR OTHERWISE) RISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
35 .\" IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
37 .\" @(#)ssA 8.1 (Berkeley) 6/8/93
43 This section discusses a number of advanced features
46 Simulating Error and Accept in Actions
48 The parsing actions of error and accept can be simulated
49 in an action by use of macros YYACCEPT and YYERROR.
52 to return the value 0;
54 the parser to behave as if the current input symbol
55 had been a syntax error;
57 is called, and error recovery takes place.
58 These mechanisms can be used to simulate parsers
59 with multiple endmarkers or context-sensitive syntax checking.
61 Accessing Values in Enclosing Rules.
63 An action may refer to values
64 returned by actions to the left of the current rule.
65 The mechanism is simply the same as with ordinary actions,
66 a dollar sign followed by a digit, but in this case the
67 digit may be 0 or negative.
70 sent : adj noun verb adj noun
71 { \fIlook at the sentence\fR . . . }
74 adj : THE { $$ = THE; }
75 | YOUNG { $$ = YOUNG; }
90 In the action following the word CRONE, a check is made that the
91 preceding token shifted was not YOUNG.
92 Obviously, this is only possible when a great deal is known about
93 what might precede the symbol
96 There is also a distinctly unstructured flavor about this.
97 Nevertheless, at times this mechanism will save a great
98 deal of trouble, especially when a few combinations are to
99 be excluded from an otherwise regular structure.
101 Support for Arbitrary Value Types
103 By default, the values returned by actions and the lexical analyzer are integers.
104 Yacc can also support
105 values of other types, including structures.
106 In addition, Yacc keeps track of the types, and inserts
107 appropriate union member names so that the resulting parser will
108 be strictly type checked.
109 The Yacc value stack (see Section 4)
112 of the various types of values desired.
113 The user declares the union, and associates union member names
114 to each token and nonterminal symbol having a value.
115 When the value is referenced through a $$ or $n construction,
116 Yacc will automatically insert the appropriate union name, so that
117 no unwanted conversions will take place.
118 In addition, type checking commands such as
121 Johnson Lint Checker 1273
123 will be far more silent.
125 There are three mechanisms used to provide for this typing.
126 First, there is a way of defining the union; this must be
127 done by the user since other programs, notably the lexical analyzer,
128 must know about the union member names.
129 Second, there is a way of associating a union member name with tokens
131 Finally, there is a mechanism for describing the type of those
132 few values where Yacc can not easily determine the type.
134 To declare the union, the user includes in the declaration section:
140 This declares the Yacc value stack,
141 and the external variables
145 to have type equal to this union.
146 If Yacc was invoked with the
148 option, the union declaration
153 the union may be declared in a header file, and a typedef
154 used to define the variable YYSTYPE to represent
156 Thus, the header file might also have said:
162 The header file must be included in the declarations
163 section, by use of %{ and %}.
165 Once YYSTYPE is defined,
166 the union member names must be associated
167 with the various terminal and nonterminal names.
172 is used to indicate a union member name.
176 %left, %right, and %nonassoc,
177 the union member name is associated with the tokens listed.
180 %left <optype> \'+\' \'\-\'
182 will cause any reference to values returned by these two tokens to be
184 the union member name
186 Another keyword, %type, is
187 used similarly to associate
188 union member names with nonterminals.
191 %type <nodetype> expr stat
194 There remain a couple of cases where these mechanisms are insufficient.
195 If there is an action within a rule, the value returned
196 by this action has no
199 Similarly, reference to left context values (such as $0 \- see the
200 previous subsection ) leaves Yacc with no easy way of knowing the type.
201 In this case, a type can be imposed on the reference by inserting
202 a union member name, between < and >, immediately after
204 An example of this usage is
206 rule : aaa { $<intval>$ = 3; } bbb
207 { fun( $<intval>2, $<other>0 ); }
210 This syntax has little to recommend it, but the situation arises rarely.
212 A sample specification is given in Appendix C.
213 The facilities in this subsection are not triggered until they are used:
214 in particular, the use of %type will turn on these mechanisms.
215 When they are used, there is a fairly strict level of checking.
216 For example, use of $n or $$ to refer to something with no defined type
218 If these facilities are not triggered, the Yacc value stack is used to
221 as was true historically.