share/doc/psd/15.yacc/ss10

   1 .\" Copyright (C) Caldera International Inc. 2001-2002.  All rights reserved.
   2 .\"
   3 .\" Redistribution and use in source and binary forms, with or without
   4 .\" modification, are permitted provided that the following conditions are
   5 .\" met:
   6 .\"
   7 .\" Redistributions of source code and documentation must retain the above
   8 .\" copyright notice, this list of conditions and the following
   9 .\" disclaimer.
  10 .\"
  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.
  14 .\"
  15 .\" All advertising materials mentioning features or use of this software
  16 .\" must display the following acknowledgement:
  17 .\"
  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
  22 .\" permission.
  23 .\"
  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.
  36 .\"
  37 .\"     @(#)ssA 8.1 (Berkeley) 6/8/93
  38 .\"
  39 .\" $FreeBSD$
  40 .SH
  41 10: Advanced Topics
  42 .PP
  43 This section discusses a number of advanced features
  44 of Yacc.
  45 .SH
  46 Simulating Error and Accept in Actions
  47 .PP
  48 The parsing actions of error and accept can be simulated
  49 in an action by use of macros YYACCEPT and YYERROR.
  50 YYACCEPT causes
  51 .I yyparse
  52 to return the value 0;
  53 YYERROR causes
  54 the parser to behave as if the current input symbol
  55 had been a syntax error;
  56 .I yyerror
  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.
  60 .SH
  61 Accessing Values in Enclosing Rules.
  62 .PP
  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.
  68 Consider
  69 .DS
  70 sent    :       adj  noun  verb  adj  noun
  71                         {  \fIlook at the sentence\fR . . .  }
  72         ;
  73
  74 adj     :       THE             {       $$ = THE;  }
  75         |       YOUNG   {       $$ = YOUNG;  }
  76         . . .
  77         ;
  78
  79 noun    :       DOG
  80                         {       $$ = DOG;  }
  81         |       CRONE
  82                         {       if( $0 == YOUNG ){
  83                                         printf( "what?\en" );
  84                                         }
  85                                 $$ = CRONE;
  86                                 }
  87         ;
  88         . . .
  89 .DE
  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
  94 .I noun
  95 in the input.
  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.
 100 .SH
 101 Support for Arbitrary Value Types
 102 .PP
 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)
 110 is declared to be a
 111 .I union
 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
 119 .I Lint\|
 120 .[
 121 Johnson Lint Checker 1273
 122 .]
 123 will be far more silent.
 124 .PP
 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
 130 and nonterminals.
 131 Finally, there is a mechanism for describing the type of those
 132 few values where Yacc can not easily determine the type.
 133 .PP
 134 To declare the union, the user includes in the declaration section:
 135 .DS
 136 %union  {
 137         body of union ...
 138         }
 139 .DE
 140 This declares the Yacc value stack,
 141 and the external variables
 142 .I yylval
 143 and
 144 .I yyval ,
 145 to have type equal to this union.
 146 If Yacc was invoked with the
 147 .B \-d
 148 option, the union declaration
 149 is copied onto the
 150 .I y.tab.h
 151 file.
 152 Alternatively,
 153 the union may be declared in a header file, and a typedef
 154 used to define the variable YYSTYPE to represent
 155 this union.
 156 Thus, the header file might also have said:
 157 .DS
 158 typedef union {
 159         body of union ...
 160         } YYSTYPE;
 161 .DE
 162 The header file must be included in the declarations
 163 section, by use of %{ and %}.
 164 .PP
 165 Once YYSTYPE is defined,
 166 the union member names must be associated
 167 with the various terminal and nonterminal names.
 168 The construction
 169 .DS
 170 < name >
 171 .DE
 172 is used to indicate a union member name.
 173 If this follows
 174 one of the
 175 keywords %token,
 176 %left, %right, and %nonassoc,
 177 the union member name is associated with the tokens listed.
 178 Thus, saying
 179 .DS
 180 %left  <optype>  \'+\'  \'\-\'
 181 .DE
 182 will cause any reference to values returned by these two tokens to be
 183 tagged with
 184 the union member name
 185 .I optype .
 186 Another keyword, %type, is
 187 used similarly to associate
 188 union member names with nonterminals.
 189 Thus, one might say
 190 .DS
 191 %type  <nodetype>  expr  stat
 192 .DE
 193 .PP
 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
 197 .I "a priori"
 198 type.
 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
 203 the first $.
 204 An example of this usage is
 205 .DS
 206 rule    :       aaa  {  $<intval>$  =  3;  } bbb
 207                         {       fun( $<intval>2, $<other>0 );  }
 208         ;
 209 .DE
 210 This syntax has little to recommend it, but the situation arises rarely.
 211 .PP
 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
 217 is diagnosed.
 218 If these facilities are not triggered, the Yacc value stack is used to
 219 hold
 220 .I int' s,
 221 as was true historically.