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

NAME

6       Yacc - an LALR(1) parser generator
7

SYNOPSIS

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

EXTENSIONS

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

PORTABILITY

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

DIAGNOSTICS

303       If  there are rules that are never reduced, the number of such rules is
304       reported on standard error.  If there are any  LALR(1)  conflicts,  the
305       number of conflicts is reported on standard error.
306
307
308
309Berkeley Yacc                 September 10, 2020                       YACC(1)
Impressum