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

EXTENSIONS

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

PORTABILITY

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

DIAGNOSTICS

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