1YACC(1)                          User Commands                         YACC(1)
2
3
4

NAME

6       Yacc - an LALR(1) parser generator
7

SYNOPSIS

9       yacc  [  -BdghilLPrtvVy  ]  [ -b file_prefix ] [ -H defines_file ] [ -o
10       output_file ] [ -p symbol_prefix ] filename
11

DESCRIPTION

13       Yacc reads the grammar specification in the file filename and generates
14       an  LALR(1)  parser  for  it.   The parsers consist of a set of LALR(1)
15       parsing tables and a driver routine written in the C  programming  lan‐
16       guage.  Yacc normally writes the parse tables and the driver routine to
17       the file y.tab.c.
18
19       The following options are available:
20
21       -b file_prefix
22            The -b option changes the prefix  prepended  to  the  output  file
23            names to the string denoted by file_prefix.  The default prefix is
24            the character y.
25
26       -B   create a backtracking parser (compile-time configuration for  bty‐
27            acc).
28
29       -d   causes  the  header  file y.tab.h to be written.  It contains #de‐
30            fine's for the token identifiers.
31
32       -h   print a usage message.
33
34       -H defines_file
35            causes #define's for the token identifiers to be  written  to  the
36            given defines_file rather than the y.tab.h file used by the -d op‐
37            tion.
38
39       -g   The -g option causes a  graphical  description  of  the  generated
40            LALR(1) parser to be written to the file y.dot in graphviz format,
41            ready to be processed by dot(1).
42
43       -i   The -i option causes a supplementary header  file  y.tab.i  to  be
44            written.   It  contains extern declarations and supplementary #de‐
45            fine's as needed to map the conventional yacc yy-prefixed names to
46            whatever  the -p option may specify.  The code file, e.g., y.tab.c
47            is modified to #include this file as well as the y.tab.h file, en‐
48            forcing consistent usage of the symbols defined in those files.
49
50            The  supplementary header file makes it simpler to separate compi‐
51            lation of lex- and yacc-files.
52
53       -l   If the -l option is not specified, yacc will insert  #line  direc‐
54            tives  in the generated code.  The #line directives let the C com‐
55            piler relate errors in the generated code to the  user's  original
56            code.   If  the  -l  option is specified, yacc will not insert the
57            #line directives.  #line directives specified by the user will  be
58            retained.
59
60       -L   enable  position processing, e.g., “%locations” (compile-time con‐
61            figuration for btyacc).
62
63       -o output_file
64            specify the filename for the parser file.  If this option  is  not
65            given,  the  output  filename is the file prefix concatenated with
66            the file suffix, e.g., y.tab.c.  This overrides the -b option.
67
68       -p symbol_prefix
69            The -p option changes the prefix prepended to yacc-generated  sym‐
70            bols  to  the string denoted by symbol_prefix.  The default prefix
71            is the string yy.
72
73       -P   create a reentrant parser, e.g., “%pure-parser”.
74
75       -r   The -r option causes yacc to produce separate files for  code  and
76            tables.   The  code file is named y.code.c, and the tables file is
77            named y.tab.c.  The prefix “y.” can be overridden using the -b op‐
78            tion.
79
80       -s   suppress  “#define”  statements generated for string literals in a
81%token” statement, to more closely match original yacc behavior.
82
83            Normally when yacc sees a line such as
84
85              %token OP_ADD "ADD"
86
87            it notices that the quoted “ADD” is a valid C identifier, and gen‐
88            erates a #define not only for OP_ADD, but for ADD as well, e.g.,
89
90              #define OP_ADD 257
91              #define ADD 258
92
93            The  original yacc does not generate the second “#define”.  The -s
94            option suppresses this “#define”.
95
96            POSIX (IEEE 1003.1 2004) documents  only  names  and  numbers  for
97%token”, though original yacc and bison also accept string liter‐
98            als.
99
100       -t   The -t option changes the  preprocessor  directives  generated  by
101            yacc so that debugging statements will be incorporated in the com‐
102            piled code.
103
104       -v   The -v option causes a human-readable description of the generated
105            parser to be written to the file y.output.
106
107       -V   print the version number to the standard output.
108
109       -y   yacc  ignores  this  option,  which  bison supports for ostensible
110            POSIX compatibility.
111
112       The filename parameter is not optional.  However, yacc accepts a single
113       “-”  to read the grammar from the standard input.  A double “--” marker
114       denotes the end of options.  A single filename  parameter  is  expected
115       after a “--” marker.
116

EXTENSIONS

118       Yacc  provides  some  extensions for compatibility with bison and other
119       implementations of yacc.  It accepts several long  options  which  have
120       equivalents  in  yacc.   The  %destructor  and  %locations features are
121       available only if yacc has been configured and compiled to support  the
122       back-tracking  (btyacc)  functionality.  The remaining features are al‐
123       ways available:
124
125        %code keyword { code }
126              Adds the indicated source code at a given point  in  the  output
127              file.  The optional keyword tells yacc where to insert the code:
128
129              top  just  after  the  version-definition in the generated code-
130                   file.
131
132              requires
133                   just after the declaration of public parser variables.   If
134                   the  -d option is given, the code is inserted at the begin‐
135                   ning of the defines-file.
136
137              provides
138                   just after the declaration of private parser variables.  If
139                   the  -d option is given, the code is inserted at the end of
140                   the defines-file.
141
142              If no keyword is given, the code is inserted at the beginning of
143              the  section of code copied verbatim from the source file.  Mul‐
144              tiple %code directives may be given; yacc inserts those into the
145              corresponding  code-  or defines-file in the order that they ap‐
146              pear in the source file.
147
148        %destructor { code } symbol+
149              defines code that is invoked when a symbol is automatically dis‐
150              carded  during error recovery.  This code can be used to reclaim
151              dynamically allocated memory associated with  the  corresponding
152              semantic  value  for  cases where user actions cannot manage the
153              memory explicitly.
154
155              On encountering a parse error,  the  generated  parser  discards
156              symbols  on  the stack and input tokens until it reaches a state
157              that will allow parsing to continue.  This  error  recovery  ap‐
158              proach results in a memory leak if the YYSTYPE value is, or con‐
159              tains, pointers to dynamically allocated memory.
160
161              The bracketed code is invoked whenever the parser  discards  one
162              of  the  symbols.  Within code, “$$” or “$<tag>$” designates the
163              semantic value associated with the discarded  symbol,  and  “@$
164              designates its location (see %locations directive).
165
166              A  per-symbol  destructor is defined by listing a grammar symbol
167              in symbol+.  A per-type destructor is defined by listing  a  se‐
168              mantic  type  tag (e.g., “<some_tag>”) in symbol+; in this case,
169              the parser will invoke code whenever  it  discards  any  grammar
170              symbol  that  has that semantic type tag, unless that symbol has
171              its own per-symbol destructor.
172
173              Two categories of default destructor are supported that are  in‐
174              voked  when discarding any grammar symbol that has no per-symbol
175              and no per-type destructor:
176
177              •   the code for “<*>” is used for grammar symbols that have  an
178                  explicitly declared semantic type tag (via “%type”);
179
180              •   the  code  for “<>” is used for grammar symbols that have no
181                  declared semantic type tag.
182
183        %expect number
184              tells yacc the expected number of shift/reduce conflicts.   That
185              makes it only report the number if it differs.
186
187        %expect-rr number
188              tell  yacc the expected number of reduce/reduce conflicts.  That
189              makes it only report the number if it differs.  This is  (unlike
190              bison) allowable in LALR parsers.
191
192        %locations
193              tells  yacc to enable management of position information associ‐
194              ated with each token, provided by the lexer in the global  vari‐
195              able yylloc, similar to management of semantic value information
196              provided in yylval.
197
198              As for semantic values, locations can be referenced  within  ac‐
199              tions  using  @$  to refer to the location of the left hand side
200              symbol, and @N (N an integer) to refer to the location of one of
201              the  right hand side symbols.  Also as for semantic values, when
202              a rule is matched, a default action is used the compute the  lo‐
203              cation  represented  by  @$ as the beginning of the first symbol
204              and the end of the last symbol in the right  hand  side  of  the
205              rule.   This  default  computation can be overridden by explicit
206              assignment to @$ in a rule action.
207
208              The type of yylloc is YYLTYPE, which is defined by default as:
209
210              typedef struct YYLTYPE {
211                  int first_line;
212                  int first_column;
213                  int last_line;
214                  int last_column;
215              } YYLTYPE;
216
217              YYLTYPE can be redefined by the user (YYLTYPE_IS_DEFINED must be
218              defined,  to inhibit the default) in the declarations section of
219              the specification file.  As in bison, the  macro  YYLLOC_DEFAULT
220              is  invoked  each time a rule is matched to calculate a position
221              for the left hand side of the rule, before the associated action
222              is executed; this macro can be redefined by the user.
223
224              This  directive  adds  a YYLTYPE parameter to yyerror().  If the
225              %pure-parser directive is present, a YYLTYPE parameter is  added
226              to yylex() calls.
227
228        %lex-param { argument-declaration }
229              By default, the lexer accepts no parameters, e.g., yylex().  Use
230              this directive to add parameter declarations for your customized
231              lexer.
232
233        %parse-param { argument-declaration }
234              By  default,  the parser accepts no parameters, e.g., yyparse().
235              Use this directive to add parameter declarations for  your  cus‐
236              tomized parser.
237
238        %pure-parser
239              Most variables (other than yydebug and yynerrs) are allocated on
240              the stack within yyparse, making  the  parser  reasonably  reen‐
241              trant.
242
243        %token-table
244              Make  the parser's names for tokens available in the yytname ar‐
245              ray.  However, yacc does not predefine “$end”, “$error” or “$un‐
246              defined” in this array.
247

PORTABILITY

249       According to Robert Corbett,
250
251              Berkeley Yacc is an LALR(1) parser generator.  Berkeley Yacc
252              has been made as compatible as possible with AT&T Yacc.
253              Berkeley Yacc can accept any input specification that
254              conforms to the AT&T Yacc documentation.  Specifications
255              that take advantage of undocumented features of AT&T Yacc
256              will probably be rejected.
257
258       The rationale in
259
260              http://pubs.opengroup.org/onlinepubs/9699919799/utilities/yacc.html
261
262       documents  some  features of AT&T yacc which are no longer required for
263       POSIX compliance.
264
265       That said, you may be interested in reusing  grammar  files  with  some
266       other  implementation  which is not strictly compatible with AT&T yacc.
267       For instance, there is bison.  Here are a few differences:
268
269Yacc accepts an equals mark preceding the left curly  brace  of  an
270           action (as in the original grammar file ftp.y):
271
272                  |   STAT CRLF
273                      = {
274                              statcmd();
275                      }
276
277Yacc  and bison emit code in different order, and in particular bi‐
278           son makes forward reference to common functions such as yylex,  yy‐
279           parse and yyerror without providing prototypes.
280
281       •   Bison's  support  for “%expect” is broken in more than one release.
282           For best results using bison, delete that directive.
283
284       •   Bison has no equivalent for some of  yacc's  command-line  options,
285           relying on directives embedded in the grammar file.
286
287       •   Bison's  “-y”  option  does  not affect bison's lack of support for
288           features of AT&T yacc which were deemed obsolescent.
289
290Yacc accepts multiple parameters with %lex-param  and  %parse-param
291           in two forms
292
293              {type1 name1} {type2 name2} ...
294              {type1 name1,  type2 name2 ...}
295
296           Bison  accepts  the  latter (though undocumented), but depending on
297           the release may generate bad code.
298
299       •   Like bison, yacc will add parameters specified via %parse-param  to
300           yyparse,  yyerror  and (if configured for back-tracking) to the de‐
301           structor declared using %destructor.  Bison puts the additional pa‐
302           rameters  first  for  yyparse and yyerror but last for destructors.
303           Yacc matches this behavior.
304

DIAGNOSTICS

306       If there are rules that are never reduced, the number of such rules  is
307       reported  on  standard  error.  If there are any LALR(1) conflicts, the
308       number of conflicts is reported on standard error.
309
310
311
312Berkeley Yacc                   March 28, 2021                         YACC(1)
Impressum