info bison

3.7.12 Bison Declaration Summary

Here is a summary of the declarations used to define a grammar:

Directive: %union: Declare the collection of data types that semantic values may have (see section The Collection of Value Types).

Directive: %token: Declare a terminal symbol (token type name) with no precedence or associativity specified (see section Token Type Names).

Directive: %right: Declare a terminal symbol (token type name) that is right-associative (see section Operator Precedence).

Directive: %left: Declare a terminal symbol (token type name) that is left-associative (see section Operator Precedence).

Directive: %nonassoc: Declare a terminal symbol (token type name) that is nonassociative (see section Operator Precedence). Using it in a way that would be associative is a syntax error.

Directive: %type: Declare the type of semantic values for a nonterminal symbol (see section Nonterminal Symbols).

Directive: %start: Specify the grammar's start symbol (see section The Start-Symbol).

Directive: %expect: Declare the expected number of shift-reduce conflicts (see section Suppressing Conflict Warnings).

In order to change the behavior of bison, use the following directives:

Directive: %code {code}

This is the unqualified form of the %code directive. It inserts code verbatim at a language-dependent default location in the output(1).

For C/C++, the default location is the parser source code file after the usual contents of the parser header file. Thus, %code replaces the traditional Yacc prologue, %{code%}, for most purposes. For a detailed discussion, see Prologue Alternatives.

For Java, the default location is inside the parser class.

(Like all the Yacc prologue alternatives, this directive is experimental. More user feedback will help to determine whether it should become a permanent feature.)

Directive: %code qualifier {code}

This is the qualified form of the %code directive. If you need to specify location-sensitive verbatim code that does not belong at the default location selected by the unqualified %code form, use this form instead.

qualifier identifies the purpose of code and thus the location(s) where Bison should generate it. Not all values of qualifier are available for all target languages:

requires
- Language(s): C, C++
- Purpose: This is the best place to write dependency code required for YYSTYPE and YYLTYPE. In other words, it's the best place to define types referenced in %union directives, and it's the best place to override Bison's default YYSTYPE and YYLTYPE definitions.
- Location(s): The parser header file and the parser source code file before the Bison-generated YYSTYPE and YYLTYPE definitions.
provides
- Language(s): C, C++
- Purpose: This is the best place to write additional definitions and declarations that should be provided to other modules.
- Location(s): The parser header file and the parser source code file after the Bison-generated YYSTYPE, YYLTYPE, and token definitions.
top
- Language(s): C, C++
- Purpose: The unqualified %code or %code requires should usually be more appropriate than %code top. However, occasionally it is necessary to insert code much nearer the top of the parser source code file. For example:
  %code top { #define _GNU_SOURCE #include <stdio.h> }
- Location(s): Near the top of the parser source code file.
imports
- Language(s): Java
- Purpose: This is the best place to write Java import directives.
- Location(s): The parser Java file after any Java package directive and before any class definitions.

(Like all the Yacc prologue alternatives, this directive is experimental. More user feedback will help to determine whether it should become a permanent feature.)

For a detailed discussion of how to use %code in place of the traditional Yacc prologue for C/C++, see Prologue Alternatives.

Directive: %debug: In the parser file, define the macro YYDEBUG to 1 if it is not already defined, so that the debugging facilities are compiled.

See section Tracing Your Parser.

Directive: %define variable

Directive: %define variable "value"

Define a variable to adjust Bison's behavior. The possible choices for variable, as well as their meanings, depend on the selected target language and/or the parser skeleton (see section %language, see section %skeleton).

Bison will warn if a variable is defined multiple times.

Omitting "value" is always equivalent to specifying it as "".

Some variables may be used as Booleans. In this case, Bison will complain if the variable definition does not meet one of the following four conditions:

"value" is "true"
"value" is omitted (or is ""). This is equivalent to "true".
"value" is "false".
variable is never defined. In this case, Bison selects a default value, which may depend on the selected target language and/or parser skeleton.

Some of the accepted variables are:

api.pure
- Language(s): C
- Purpose: Request a pure (reentrant) parser program. See section A Pure (Reentrant) Parser.
- Accepted Values: Boolean
- Default Value: "false"
api.push_pull
- Language(s): C (LALR(1) only)
- Purpose: Requests a pull parser, a push parser, or both. See section A Push Parser. (The current push parsing interface is experimental and may evolve. More user feedback will help to stabilize it.)
- Accepted Values: "pull", "push", "both"
- Default Value: "pull"
lr.keep_unreachable_states
- Language(s): all
- Purpose: Requests that Bison allow unreachable parser states to remain in the parser tables. Bison considers a state to be unreachable if there exists no sequence of transitions from the start state to that state. A state can become unreachable during conflict resolution if Bison disables a shift action leading to it from a predecessor state. Keeping unreachable states is sometimes useful for analysis purposes, but they are useless in the generated parser.
- Accepted Values: Boolean
- Default Value: "false"
- Caveats:
  - Unreachable states may contain conflicts and may use rules not used in any other state. Thus, keeping unreachable states may induce warnings that are irrelevant to your parser's behavior, and it may eliminate warnings that are relevant. Of course, the change in warnings may actually be relevant to a parser table analysis that wants to keep unreachable states, so this behavior will likely remain in future Bison releases.
  - While Bison is able to remove unreachable states, it is not guaranteed to remove other kinds of useless states. Specifically, when Bison disables reduce actions during conflict resolution, some goto actions may become useless, and thus some additional states may become useless. If Bison were to compute which goto actions were useless and then disable those actions, it could identify such states as unreachable and then remove those states. However, Bison does not compute which goto actions are useless.
namespace
- Languages(s): C++
- Purpose: Specifies the namespace for the parser class. For example, if you specify:
  %define namespace "foo::bar"
  Bison uses foo::bar verbatim in references such as:
  foo::bar::parser::semantic_type
  However, to open a namespace, Bison removes any leading :: and then splits on any remaining occurrences:
  namespace foo { namespace bar { class position; class location; } }
- Accepted Values: Any absolute or relative C++ namespace reference without a trailing "::". For example, "foo" or "::foo::bar".
- Default Value: The value specified by %name-prefix, which defaults to yy. This usage of %name-prefix is for backward compatibility and can be confusing since %name-prefix also specifies the textual prefix for the lexical analyzer function. Thus, if you specify %name-prefix, it is best to also specify %define namespace so that %name-prefix only affects the lexical analyzer function. For example, if you specify:
  %define namespace "foo" %name-prefix "bar::"
  The parser namespace is foo and yylex is referenced as bar::lex.

Directive: %defines

Write a header file containing macro definitions for the token type names defined in the grammar as well as a few other declarations. If the parser output file is named ‘name.c’ then this file is named ‘name.h’.

For C parsers, the output header 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 section More Than One Value Type) with components that require other definitions, or if you have defined a YYSTYPE macro or type definition (see section 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 output header declares yylval as an external variable. See section A Pure (Reentrant) Parser.

If you have also used locations, the output header declares YYLTYPE and yylloc using a protocol similar to that of the YYSTYPE macro and yylval. See section Tracking Locations.

This output 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 type codes. See section Semantic Values of Tokens.

If you have declared %code requires or %code provides, the output header also contains their code. See section %code.

Directive: %defines defines-file: Same as above, but save in the file defines-file.

Directive: %destructor: Specify how the parser should reclaim the memory associated to discarded symbols. See section Freeing Discarded Symbols.

Directive: %file-prefix "prefix": Specify a prefix to use for all Bison output file names. The names are chosen as if the input file were named ‘prefix.y’.

Directive: %language "language"

Specify the programming language for the generated parser. Currently supported languages include C, C++, and Java. language is case-insensitive.

This directive is experimental and its effect may be modified in future releases.

Directive: %locations: Generate the code processing the locations (see section 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.

Directive: %name-prefix "prefix": 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. For C++ parsers, see the %define namespace documentation in this section. See section Multiple Parsers in the Same Program.

Directive: %no-lines: Don't generate any #line preprocessor commands in the parser file. Ordinarily Bison writes these commands in the parser 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 file, treating it an independent source file in its own right.

Directive: %output "file": Specify file for the parser file.

Directive: %pure-parser: Deprecated version of %define api.pure (see section %define), for which Bison is more careful to warn about unreasonable usage.

Directive: %require "version": Require version version or higher of Bison. See section Require a Version of Bison.

Directive: %skeleton "file"

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.

Directive: %token-table

Generate an array of token names in the parser file. The name of the array is yytname; yytname[i] is the name of the token whose internal Bison token code number 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:

YYNTOKENS: The highest token number, plus one.
YYNNTS: The number of nonterminal symbols.
YYNRULES: The number of grammar rules,
YYNSTATES: The number of parser states (see section Parser States).

Directive: %verbose: 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 section Understanding Your Parser, for more information.

Directive: %yacc: Pretend the option ‘--yacc’ was given, i.e., imitate Yacc, including its naming conventions. See section Bison Options, for more.

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top]

[Contents]

[Index]

[ ? ]