Next: %define Summary, Previous: A Push Parser, Up: Bison Declarations [Contents][Index]
Here is a summary of the declarations used to define a grammar:
Declare the collection of data types that semantic values may have (see The Union Declaration).
Declare a terminal symbol (token kind name) with no precedence or associativity specified (see Token Kind Names).
Declare a terminal symbol (token kind name) that is right-associative (see Operator Precedence).
Declare a terminal symbol (token kind name) that is left-associative (see Operator Precedence).
Declare a terminal symbol (token kind name) that is nonassociative (see Operator Precedence). Using it in a way that would be associative is a syntax error.
Declare the type of semantic values for a nonterminal symbol (see Nonterminal Symbols).
Declare the type of semantic values for a symbol (see Nonterminal Symbols).
Specify the grammar’s start symbol (see The Start-Symbol).
Declare the expected number of shift/reduce conflicts, either overall or for a given rule (see Suppressing Conflict Warnings).
Declare the expected number of reduce/reduce conflicts, either overall or for a given rule (see Suppressing Conflict Warnings).
In order to change the behavior of bison, use the following
directives:
Insert code verbatim into the output parser source at the default location or at the location specified by qualifier. See %code Summary.
Instrument the parser for traces. Obsoleted by ‘%define parse.trace’. See Tracing Your Parser.
Define a variable to adjust Bison’s behavior. See %define Summary.
Specify how the parser should reclaim the memory associated to discarded symbols. See Freeing Discarded Symbols.
Specify a prefix to use for all Bison output file names. The names are chosen as if the grammar file were named prefix.y.
Write a parser header file containing definitions for the token kind names defined in the grammar as well as a few other declarations. If the parser implementation file is named name.c then the parser header file is named name.h.
For C parsers, the parser header file declares YYSTYPE unless
YYSTYPE is already defined as a macro or you have used a
<type> tag without using %union. Therefore, if you are
using a %union (see More Than One Value Type) with components that require
other definitions, or if you have defined a YYSTYPE macro or type
definition (see Data Types of Semantic Values), you need to arrange for these definitions
to be propagated to all modules, e.g., by putting them in a prerequisite
header that is included both by your parser and by any other module that
needs YYSTYPE.
Unless your parser is pure, the parser header file declares
yylval as an external variable. See A Pure (Reentrant) Parser.
If you have also used locations, the parser header file declares
YYLTYPE and yylloc using a protocol similar to that of the
YYSTYPE macro and yylval. See Tracking Locations.
This parser header file is normally essential if you wish to put the
definition of yylex in a separate source file, because
yylex typically needs to be able to refer to the
above-mentioned declarations and to the token kind codes. See Semantic Values of Tokens.
If you have declared %code requires or %code provides, the output
header also contains their code.
See %code Summary.
The generated header is protected against multiple inclusions with a C preprocessor guard: ‘YY_PREFIX_FILE_INCLUDED’, where PREFIX and FILE are the prefix (see Multiple Parsers in the Same Program) and generated file name turned uppercase, with each series of non alphanumerical characters converted to a single underscore.
For instance with ‘%define api.prefix {calc}’ and ‘%header "lib/parse.h"’, the header will be guarded as follows.
#ifndef YY_CALC_LIB_PARSE_H_INCLUDED # define YY_CALC_LIB_PARSE_H_INCLUDED ... #endif /* ! YY_CALC_LIB_PARSE_H_INCLUDED */
Introduced in Bison 3.8.
Same as above, but save in the file header-file.
Specify the programming language for the generated parser. Currently supported languages include C, C++, D and Java. language is case-insensitive.
Generate the code processing the locations (see Special Features for Use in Actions). This mode is enabled as soon as the grammar uses the special ‘@n’ tokens, but if your grammar does not use it, using ‘%locations’ allows for more accurate syntax error messages.
Obsoleted by ‘%define api.prefix {prefix}’. See Multiple Parsers in the Same Program. For C++ parsers, see the ‘%define api.namespace’ documentation in this section.
Rename the external symbols used in the parser so that they start with
prefix instead of ‘yy’. The precise list of symbols renamed in C
parsers is yyparse, yylex, yyerror, yynerrs,
yylval, yychar, yydebug, and (if locations are used)
yylloc. If you use a push parser, yypush_parse,
yypull_parse, yypstate, yypstate_new and
yypstate_delete will also be renamed. For example, if you use
‘%name-prefix "c_"’, the names become c_parse, c_lex, and
so on.
Contrary to defining api.prefix, some symbols are not renamed
by %name-prefix, for instance YYDEBUG, YYTOKENTYPE,
yytoken_kind_t, YYSTYPE, YYLTYPE.
Don’t generate any #line preprocessor commands in the parser
implementation file. Ordinarily Bison writes these commands in the parser
implementation file so that the C compiler and debuggers will associate
errors and object code with your source file (the grammar file). This
directive causes them to associate errors with the parser implementation
file, treating it as an independent source file in its own right.
Generate the parser implementation in file.
Deprecated version of ‘%define api.pure’ (see %define Summary), for which Bison is more careful to warn about unreasonable usage.
Require version version or higher of Bison. See Require a Version of Bison.
Specify the skeleton to use.
If file does not contain a /, file is the name of a skeleton
file in the Bison installation directory.
If it does, file is an absolute file name or a file name relative to the
directory of the grammar file.
This is similar to how most shells resolve commands.
This feature is obsolescent, avoid it in new projects.
Generate an array of token names in the parser implementation file. The
name of the array is yytname; yytname[i] is the name of
the token whose internal Bison token code is i. The first three
elements of yytname correspond to the predefined tokens
"$end", "error", and "$undefined"; after these come the
symbols defined in the grammar file.
The name in the table includes all the characters needed to represent the
token in Bison. For single-character literals and literal strings, this
includes the surrounding quoting characters and any escape sequences. For
example, the Bison single-character literal '+' corresponds to a
three-character name, represented in C as "'+'"; and the Bison
two-character literal string "\\/" corresponds to a five-character
name, represented in C as "\"\\\\/\"".
When you specify %token-table, Bison also generates macro definitions
for macros YYNTOKENS, YYNNTS, and YYNRULES, and
YYNSTATES:
YYNTOKENSThe number of terminal symbols, i.e., the highest token code, plus one.
YYNNTSThe number of nonterminal symbols.
YYNRULESThe number of grammar rules,
YYNSTATESThe number of parser states (see Parser States).
Here’s code for looking up a multicharacter token in yytname,
assuming that the characters of the token are stored in token_buffer,
and assuming that the token does not contain any characters like ‘"’
that require escaping.
for (int i = 0; i < YYNTOKENS; i++)
if (yytname[i]
&& yytname[i][0] == '"'
&& ! strncmp (yytname[i] + 1, token_buffer,
strlen (token_buffer))
&& yytname[i][strlen (token_buffer) + 1] == '"'
&& yytname[i][strlen (token_buffer) + 2] == 0)
break;
This method is discouraged: the primary purpose of string aliases is forging good error messages, not describing the spelling of keywords. In addition, looking for the token kind at runtime incurs a (small but noticeable) cost.
Finally, %token-table is incompatible with the custom and
detailed values of the parse.error %define variable.
Write an extra output file containing verbose descriptions of the parser states and what is done for each type of lookahead token in that state. See Understanding Your Parser, for more information.
Pretend the option --yacc was given (see --yacc), i.e., imitate Yacc, including its naming conventions. Only makes sense with the yacc.c skeleton. See Tuning the Parser, for more.
Of course, being a Bison extension, %yacc is somewhat
self-contradictory…
Next: %define Summary, Previous: A Push Parser, Up: Bison Declarations [Contents][Index]