Next: %code Summary, Previous: Decl Summary, Up: Declarations [Contents][Index]
There are many features of Bison’s behavior that can be controlled by
assigning the feature a single value. For historical reasons, some
such features are assigned values by dedicated directives, such as
%start
, which assigns the start symbol. However, newer such
features are associated with variables, which are assigned by the
%define
directive:
Define variable to value.
value must be placed in quotation marks if it contains any
character other than a letter, underscore, period, or non-initial dash
or digit. Omitting "value"
entirely is always equivalent
to specifying ""
.
It is an error if a variable is defined by %define
multiple times, but see -D
name[=value].
The rest of this section summarizes variables and values that
%define
accepts.
Some variables take Boolean values. 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 specified).
This is equivalent to true
.
value
is false
.
What variables are accepted, as well as their meanings and default values, depend on the selected target language and/or the parser skeleton (see %language, see %skeleton). Unaccepted variables produce an error. Some of the accepted variables are:
api.location.type
api.prefix
yy
api.pure
true
, false
, full
The value may be omitted: this is equivalent to specifying true
, as is
the case for Boolean values.
When %define api.pure full
is used, the parser is made reentrant. This
changes the signature for yylex
(see Pure Calling), and also that of
yyerror
when the tracking of locations has been activated, as shown
below.
The true
value is very similar to the full
value, the only
difference is in the signature of yyerror
on Yacc parsers without
%parse-param
, for historical reasons.
I.e., if ‘%locations %define api.pure’ is passed then the prototypes for
yyerror
are:
void yyerror (char const *msg); // Yacc parsers. void yyerror (YYLTYPE *locp, char const *msg); // GLR parsers.
But if ‘%locations %define api.pure %parse-param {int *nastiness}’ is used, then both parsers have the same signature:
void yyerror (YYLTYPE *llocp, int *nastiness, char const *msg);
false
full
value was introduced in Bison 2.7
api.push-pull
pull
, push
, both
pull
lr.default-reductions
most
, consistent
, accepting
accepting
if lr.type
is canonical-lr
.
most
otherwise.
lr.keep-unreachable-states
false
lr.type
lalr
, ielr
, canonical-lr
lalr
namespace
%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; } }
"::"
.
For example, "foo"
or "::foo::bar"
.
%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
.
parse.lac
none
, full
none
Next: %code Summary, Previous: Decl Summary, Up: Declarations [Contents][Index]