* Java Parser Interface:: Instantiating and running the parser
* Java Scanner Interface:: Specifying the scanner for the parser
* Java Action Features:: Special features for use in actions
+* Java Push Parser Interface:: Instantiating and running the a push parser
* Java Differences:: Differences between C/C++ and Java Grammars
* Java Declarations Summary:: List of Bison declarations used with Java
%@}
@end group
-%define api.value.type double
+%define api.value.type @{double@}
%token NUM
%% /* Grammar rules and actions follow. */
groupings (@pxref{Value Type, ,Data Types of Semantic Values}). The Bison
parser will use whatever type @code{api.value.type} is defined as; if you
don't define it, @code{int} is the default. Because we specify
-@code{double}, each token and each expression has an associated value, which
-is a floating point number. C code can use @code{YYSTYPE} to refer to the
-value @code{api.value.type}.
+@samp{@{double@}}, each token and each expression has an associated value,
+which is a floating point number. C code can use @code{YYSTYPE} to refer to
+the value @code{api.value.type}.
Each terminal symbol that is not a single-character literal must be
declared. (Single-character literals normally don't need to be declared.)
global variable @code{yylval}, which is where the Bison parser will look
for it. (The C data type of @code{yylval} is @code{YYSTYPE}, whose value
was defined at the beginning of the grammar via @samp{%define api.value.type
-double}; @pxref{Rpcalc Declarations,,Declarations for @code{rpcalc}}.)
+@{double@}}; @pxref{Rpcalc Declarations,,Declarations for @code{rpcalc}}.)
A token type code of zero is returned if the end-of-input is encountered.
(Bison recognizes any nonpositive value as indicating end-of-input.)
@group
/* Bison declarations. */
-%define api.value.type double
+%define api.value.type @{double@}
%token NUM
%left '-' '+'
%left '*' '/'
%@}
/* Bison declarations. */
-%define api.value.type int
+%define api.value.type @{int@}
%token NUM
%left '-' '+'
@code{api.value.type} like this:
@example
-%define api.value.type double
+%define api.value.type @{double@}
@end example
@noindent
or
@example
-%define api.value.type "struct semantic_type"
+%define api.value.type @{struct semantic_type@}
@end example
The value of @code{api.value.type} should be a type name that does not
If the @code{%define} variable @code{api.token.prefix} is defined
(@pxref{%define Summary,,api.token.prefix}), then it is also used to prefix
the union member names. For instance, with @samp{%define api.token.prefix
-TOK_}:
+@{TOK_@}}:
@example
/* For an "integer". */
return TOK_INT;
@end example
+This Bison extension cannot work if @code{%yacc} (or
+@option{-y}/@option{--yacc}) is enabled, as POSIX mandates that Yacc
+generate tokens as macros (e.g., @samp{#define INT 258}, or @samp{#define
+TOK_INT 258}).
+
This feature is new, and user feedback would be most welcome.
A similar feature is provided for C++ that in addition overcomes C++
%@{
#include "parser.h"
%@}
-%define api.value.type "union YYSTYPE"
+%define api.value.type @{union YYSTYPE@}
%type <val> expr
%token <tptr> ID
@end group
@deffn {Directive} %define @var{variable}
@deffnx {Directive} %define @var{variable} @var{value}
+@deffnx {Directive} %define @var{variable} @{@var{value}@}
@deffnx {Directive} %define @var{variable} "@var{value}"
Define a variable to adjust Bison's behavior. @xref{%define Summary}.
@end deffn
uppercase, with each series of non alphanumerical characters converted to a
single underscore.
-For instance with @samp{%define api.prefix "calc"} and @samp{%defines
+For instance with @samp{%define api.prefix @{calc@}} and @samp{%defines
"lib/parse.h"}, the header will be guarded as follows.
@example
#ifndef YY_CALC_LIB_PARSE_H_INCLUDED
@deffn {Directive} %define @var{variable}
@deffnx {Directive} %define @var{variable} @var{value}
+@deffnx {Directive} %define @var{variable} @{@var{value}@}
@deffnx {Directive} %define @var{variable} "@var{value}"
Define @var{variable} to @var{value}.
-@var{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 @code{"@var{value}"} entirely is always equivalent
-to specifying @code{""}.
+The type of the values depend on the syntax. Braces denote value in the
+target language (e.g., a namespace, a type, etc.). Keyword values (no
+delimiters) denote finite choice (e.g., a variation of a feature). String
+values denote remaining cases (e.g., a file name).
-It is an error if a @var{variable} is defined by @code{%define}
-multiple times, but see @ref{Bison Options,,-D
-@var{name}[=@var{value}]}.
+It is an error if a @var{variable} is defined by @code{%define} multiple
+times, but see @ref{Bison Options,,-D @var{name}[=@var{value}]}.
@end deffn
The rest of this section summarizes variables and values that
@c api.namespace
@c ================================================== api.location.type
-@deffn {Directive} {%define api.location.type} @var{type}
+@deffn {Directive} {%define api.location.type} @{@var{type}@}
@itemize @bullet
@item Language(s): C++, Java
@end deffn
@c ================================================== api.prefix
-@deffn {Directive} {%define api.prefix} @var{prefix}
+@deffn {Directive} {%define api.prefix} @{@var{prefix}@}
@itemize @bullet
@item Language(s): All
@end deffn
@c ================================================== api.pure
-@deffn Directive {%define api.pure}
+@deffn Directive {%define api.pure} @var{purity}
@itemize @bullet
@item Language(s): C
@item Default Value:
@code{false}
@item History:
-introduced in Bison 2.8
+introduced in Bison 3.0
@end itemize
@end deffn
@c api.token.constructor
@c ================================================== api.token.prefix
-@deffn Directive {%define api.token.prefix} @var{prefix}
+@deffn Directive {%define api.token.prefix} @{@var{prefix}@}
@itemize
@item Languages(s): all
@example
%token FILE for ERROR
-%define api.token.prefix "TOK_"
+%define api.token.prefix @{TOK_@}
%%
start: FILE for ERROR;
@end example
@item Default Value:
empty
@item History:
-introduced in Bison 2.8
+introduced in Bison 3.0
@end itemize
@end deffn
@c api.token.prefix
@c ================================================== api.value.type
-@deffn Directive {%define api.value.type} @var{type}
+@deffn Directive {%define api.value.type} @var{support}
+@deffnx Directive {%define api.value.type} @{@var{type}@}
@itemize @bullet
@item Language(s):
all
@item Accepted Values:
@table @asis
-@item @code{""}
+@item @samp{@{@}}
This grammar has no semantic value at all. This is not properly supported
yet.
-@item @code{%union} (C, C++)
+@item @samp{union-directive} (C, C++)
The type is defined thanks to the @code{%union} directive. You don't have
to define @code{api.value.type} in that case, using @code{%union} suffices.
@xref{Union Decl, ,The Union Declaration}.
For instance:
@example
-%define api.value.type "%union"
+%define api.value.type union-directive
%union
@{
int ival;
%token <sval> STR "string"
@end example
-@item @code{union} (C, C++)
+@item @samp{union} (C, C++)
The symbols are defined with type names, from which Bison will generate a
@code{union}. For instance:
@example
-%define api.value.type "union"
+%define api.value.type union
%token <int> INT "integer"
%token <char *> STR "string"
@end example
This feature needs user feedback to stabilize. Note that most C++ objects
cannot be stored in a @code{union}.
-@item @code{variant} (C++)
+@item @samp{variant} (C++)
This is similar to @code{union}, but special storage techniques are used to
allow any kind of C++ object to be used. For instance:
@example
-%define api.value.type "variant"
+%define api.value.type variant
%token <int> INT "integer"
%token <std::string> STR "string"
@end example
This feature needs user feedback to stabilize.
@xref{C++ Variants}.
-@item any other identifier
-Use this name as semantic value.
+@item @samp{@{@var{type}@}}
+Use this @var{type} as semantic value.
@example
%code requires
@{
@} u;
@};
@}
-%define api.value.type "struct my_value"
+%define api.value.type @{struct my_value@}
%token <u.ival> INT "integer"
%token <u.sval> STR "string"
@end example
@end itemize
@item History:
-introduced in Bison 2.8. Was introduced for Java only in 2.3b as
+introduced in Bison 3.0. Was introduced for Java only in 2.3b as
@code{stype}.
@end itemize
@end deffn
@item @code{most} otherwise.
@end itemize
@item History:
-introduced as @code{lr.default-reduction} in 2.5, renamed as
-@code{lr.default-reduction} in 2.8.
+introduced as @code{lr.default-reductions} in 2.5, renamed as
+@code{lr.default-reduction} in 3.0.
@end itemize
@end deffn
@item History:
introduced as @code{lr.keep_unreachable_states} in 2.3b, renamed as
@code{lr.keep-unreachable-states} in 2.5, and as
-@code{lr.keep-unreachable-state} in 2.8.
+@code{lr.keep-unreachable-state} in 3.0.
@end itemize
@end deffn
@c lr.keep-unreachable-state
@c ================================================== parse.error
-@deffn Directive {%define parse.error}
+@deffn Directive {%define parse.error} @var{verbosity}
@itemize
@item Languages(s):
all
@c ================================================== parse.lac
-@deffn Directive {%define parse.lac}
+@deffn Directive {%define parse.lac} @var{when}
@itemize
@item Languages(s): C (deterministic parsers only)
@xref{Tracing, ,Tracing Your Parser}.
In C/C++, define the macro @code{YYDEBUG} (or @code{@var{prefix}DEBUG} with
-@samp{%define api.prefix @var{prefix}}), see @ref{Multiple Parsers,
+@samp{%define api.prefix @{@var{prefix}@}}), see @ref{Multiple Parsers,
,Multiple Parsers in the Same Program}) to 1 in the parser implementation
file if it is not already defined, so that the debugging facilities are
compiled.
@code{api.prefix}. With different @code{api.prefix}s it is guaranteed that
headers do not conflict when included together, and that compiled objects
can be linked together too. Specifying @samp{%define api.prefix
-@var{prefix}} (or passing the option @samp{-Dapi.prefix=@var{prefix}}, see
+@{@var{prefix}@}} (or passing the option @samp{-Dapi.prefix=@{@var{prefix}@}}, see
@ref{Invocation, ,Invoking Bison}) renames the interface functions and
variables of the Bison parser to start with @var{prefix} instead of
@samp{yy}, and all the macros to start by @var{PREFIX} (i.e., @var{prefix}
@code{YYSTYPE}, @code{YYLTYPE}, and @code{YYDEBUG}, which is treated
specifically --- more about this below.
-For example, if you use @samp{%define api.prefix c}, the names become
+For example, if you use @samp{%define api.prefix @{c@}}, the names become
@code{cparse}, @code{clex}, @dots{}, @code{CSTYPE}, @code{CLTYPE}, and so
on.
@item the option @option{-t} (POSIX Yacc compliant)
@itemx the option @option{--debug} (Bison extension)
Use the @samp{-t} option when you run Bison (@pxref{Invocation, ,Invoking
-Bison}). With @samp{%define api.prefix c}, it defines @code{CDEBUG} to 1,
+Bison}). With @samp{%define api.prefix @{c@}}, it defines @code{CDEBUG} to 1,
otherwise it defines @code{YYDEBUG} to 1.
@item the directive @samp{%debug}
instance, @option{-Wno-yacc} will hide the warnings about
POSIX Yacc incompatibilities.
-@item -Werror[=@var{category}]
-@itemx -Wno-error[=@var{category}]
-Enable warnings falling in @var{category}, and treat them as errors. If no
-@var{category} is given, it defaults to making all enabled warnings into errors.
+@item -Werror
+Turn enabled warnings for every @var{category} into errors, unless they are
+explicitly disabled by @option{-Wno-error=@var{category}}.
+
+@item -Werror=@var{category}
+Enable warnings falling in @var{category}, and treat them as errors.
@var{category} is the same as for @option{--warnings}, with the exception that
it may not be prefixed with @samp{no-} (see above).
-Prefixed with @samp{no}, it deactivates the error treatment for this
-@var{category}. However, the warning itself won't be disabled, or enabled, by
-this option.
-
Note that the precedence of the @samp{=} and @samp{,} operators is such that
the following commands are @emph{not} equivalent, as the first will not treat
S/R conflicts as errors.
$ bison -Werror=yacc,error=conflicts-sr input.y
@end example
+@item -Wno-error
+Do not turn enabled warnings for every @var{category} into errors, unless
+they are explicitly enabled by @option{-Werror=@var{category}}.
+
+@item -Wno-error=@var{category}
+Deactivate the error treatment for this @var{category}. However, the warning
+itself won't be disabled, or enabled, by this option.
+
@item -f [@var{feature}]
@itemx --feature[=@var{feature}]
Activate miscellaneous @var{feature}. @var{feature} can be one of:
The line, starting at 1.
@end deftypeivar
-@deftypemethod {position} {uint} lines (int @var{height} = 1)
-Advance by @var{height} lines, resetting the column number.
+@deftypemethod {position} {void} lines (int @var{height} = 1)
+If @var{height} is not null, advance by @var{height} lines, resetting the
+column number. The resulting line number cannot be less than 1.
@end deftypemethod
@deftypeivar {position} {uint} column
The column, starting at 1.
@end deftypeivar
-@deftypemethod {position} {uint} columns (int @var{width} = 1)
-Advance by @var{width} columns, without changing the line number.
+@deftypemethod {position} {void} columns (int @var{width} = 1)
+Advance by @var{width} columns, without changing the line number. The
+resulting column number cannot be less than 1.
@end deftypemethod
@deftypemethod {position} {position&} operator+= (int @var{width})
The first, inclusive, position of the range, and the first beyond.
@end deftypeivar
-@deftypemethod {location} {uint} columns (int @var{width} = 1)
-@deftypemethodx {location} {uint} lines (int @var{height} = 1)
-Advance the @code{end} position.
+@deftypemethod {location} {void} columns (int @var{width} = 1)
+@deftypemethodx {location} {void} lines (int @var{height} = 1)
+Forwarded to the @code{end} position.
@end deftypemethod
@deftypemethod {location} {location} operator+ (const location& @var{end})
@deftypemethodx {location} {location} operator+ (int @var{width})
@deftypemethodx {location} {location} operator+= (int @var{width})
+@deftypemethodx {location} {location} operator- (int @var{width})
+@deftypemethodx {location} {location} operator-= (int @var{width})
Various forms of syntactic sugar.
@end deftypemethod
@code{api.location.type} to specify your own type:
@example
-%define api.location.type @var{LocationType}
+%define api.location.type @{@var{LocationType}@}
@end example
The requirements over your @var{LocationType} are:
@example
%defines
%locations
-%define namespace "master::"
+%define api.namespace @{master::@}
@end example
@noindent
files, reused by other parsers as follows:
@example
-%define api.location.type "master::location"
+%define api.location.type @{master::location@}
%code requires @{ #include <master/location.hh> @}
@end example
The output files @file{@var{output}.hh} and @file{@var{output}.cc}
declare and define the parser class in the namespace @code{yy}. The
class name defaults to @code{parser}, but may be changed using
-@samp{%define parser_class_name "@var{name}"}. The interface of
+@samp{%define parser_class_name @{@var{name}@}}. The interface of
this class is detailed below. It can be extended using the
@code{%parse-param} feature: its semantics is slightly changed since
it describes an additional member of the parser class, and an
For instance, given the following declarations:
@example
-%define api.token.prefix "TOK_"
+%define api.token.prefix @{TOK_@}
%token <std::string> IDENTIFIER;
%token <int> INTEGER;
%token COLON;
%skeleton "lalr1.cc" /* -*- C++ -*- */
%require "@value{VERSION}"
%defines
-%define parser_class_name "calcxx_parser"
+%define parser_class_name @{calcxx_parser@}
@end example
@noindent
@comment file: calc++-parser.yy
@example
-%define api.token.prefix "TOK_"
+%define api.token.prefix @{TOK_@}
%token
END 0 "end of file"
ASSIGN ":="
* Java Parser Interface:: Instantiating and running the parser
* Java Scanner Interface:: Specifying the scanner for the parser
* Java Action Features:: Special features for use in actions
+* Java Push Parser Interface:: Instantiating and running the a push parser
* Java Differences:: Differences between C/C++ and Java Grammars
* Java Declarations Summary:: List of Bison declarations used with Java
@end menu
directive. For example, after the following declaration:
@example
-%define api.value.type "ASTNode"
+%define api.value.type @{ASTNode@}
@end example
@noindent
defines a class representing a @dfn{location}, a range composed of a pair of
positions (possibly spanning several files). The location class is an inner
class of the parser; the name is @code{Location} by default, and may also be
-renamed using @code{%define api.location.type "@var{class-name}"}.
+renamed using @code{%define api.location.type @{@var{class-name}@}}.
The location class treats the position as a completely opaque value.
By default, the class name is @code{Position}, but this can be changed
-with @code{%define api.position.type "@var{class-name}"}. This class must
+with @code{%define api.position.type @{@var{class-name}@}}. This class must
be supplied by the user.
The name of the generated parser class defaults to @code{YYParser}. The
@code{YY} prefix may be changed using the @code{%name-prefix} directive
or the @option{-p}/@option{--name-prefix} option. Alternatively, use
-@samp{%define parser_class_name "@var{name}"} to give a custom name to
+@samp{%define parser_class_name @{@var{name}@}} to give a custom name to
the class. The interface of this class is detailed below.
By default, the parser class has package visibility. A declaration
file should match the name of the class in this case. Similarly, you can
use @code{abstract}, @code{final} and @code{strictfp} with the
@code{%define} declaration to add other modifiers to the parser class.
-A single @samp{%define annotations "@var{annotations}"} directive can
+A single @samp{%define annotations @{@var{annotations}@}} directive can
be used to add any number of annotations to the parser class.
The Java package name of the parser class can be specified using the
@deftypemethod {Lexer} {void} yyerror (Location @var{loc}, String @var{msg})
This method is defined by the user to emit an error message. The first
parameter is omitted if location tracking is not active. Its type can be
-changed using @code{%define api.location.type "@var{class-name}".}
+changed using @code{%define api.location.type @{@var{class-name}@}}.
@end deftypemethod
@deftypemethod {Lexer} {int} yylex ()
methods are not needed unless location tracking is active.
The return type can be changed using @code{%define api.position.type
-"@var{class-name}".}
+@{@var{class-name}@}}.
@end deftypemethod
@deftypemethod {Lexer} {Object} getLVal ()
Return the semantic value of the last token that yylex returned.
The return type can be changed using @samp{%define api.value.type
-"@var{class-name}".}
+@{@var{class-name}@}}.
@end deftypemethod
-
@node Java Action Features
@subsection Special Features for Use in Java Actions
available only if location tracking is active.
@end deftypefn
+@node Java Push Parser Interface
+@subsection Java Push Parser Interface
+@c - define push_parse
+@findex %define api.push-pull
+
+(The current push parsing interface is experimental and may evolve. More
+user feedback will help to stabilize it.)
+
+Normally, Bison generates a pull parser for Java.
+The following Bison declaration says that you want the parser to be a push
+parser (@pxref{%define Summary,,api.push-pull}):
+
+@example
+%define api.push-pull push
+@end example
+
+Most of the discussion about the Java pull Parser Interface, (@pxref{Java
+Parser Interface}) applies to the push parser interface as well.
+
+When generating a push parser, the method @code{push_parse} is created with
+the following signature (depending on if locations are enabled).
+
+@deftypemethod {YYParser} {void} push_parse ({int} @var{token}, {Object} @var{yylval})
+@deftypemethodx {YYParser} {void} push_parse ({int} @var{token}, {Object} @var{yylval}, {Location} @var{yyloc})
+@deftypemethodx {YYParser} {void} push_parse ({int} @var{token}, {Object} @var{yylval}, {Position} @var{yypos})
+@end deftypemethod
+
+The primary difference with respect to a pull parser is that the parser
+method @code{push_parse} is invoked repeatedly to parse each token. This
+function is available if either the "%define api.push-pull push" or "%define
+api.push-pull both" declaration is used (@pxref{%define
+Summary,,api.push-pull}). The @code{Location} and @code{Position}
+parameters are available only if location tracking is active.
+
+The value returned by the @code{push_parse} method is one of the following
+four constants: @code{YYABORT}, @code{YYACCEPT}, @code{YYERROR}, or
+@code{YYPUSH_MORE}. This new value, @code{YYPUSH_MORE}, may be returned if
+more input is required to finish parsing the grammar.
+
+If api.push-pull is declared as @code{both}, then the generated parser class
+will also implement the @code{parse} method. This method's body is a loop
+that repeatedly invokes the scanner and then passes the values obtained from
+the scanner to the @code{push_parse} method.
+
+There is one additional complication. Technically, the push parser does not
+need to know about the scanner (i.e. an object implementing the
+@code{YYParser.Lexer} interface), but it does need access to the
+@code{yyerror} method. Currently, the @code{yyerror} method is defined in
+the @code{YYParser.Lexer} interface. Hence, an implementation of that
+interface is still required in order to provide an implementation of
+@code{yyerror}. The current approach (and subject to change) is to require
+the @code{YYParser} constructor to be given an object implementing the
+@code{YYParser.Lexer} interface. This object need only implement the
+@code{yyerror} method; the other methods can be stubbed since they will
+never be invoked. The simplest way to do this is to add a trivial scanner
+implementation to your grammar file using whatever implementation of
+@code{yyerror} is desired. The following code sample shows a simple way to
+accomplish this.
+
+@example
+%code lexer
+@{
+ public Object getLVal () @{return null;@}
+ public int yylex () @{return 0;@}
+ public void yyerror (String s) @{System.err.println(s);@}
+@}
+@end example
@node Java Differences
@subsection Differences between C/C++ and Java Grammars
@xref{Java Bison Interface}.
@end deffn
-@deffn {Directive} {%define annotations} "@var{annotations}"
+@deffn {Directive} {%define annotations} @{@var{annotations}@}
The Java annotations for the parser class. Default is none.
@xref{Java Bison Interface}.
@end deffn
-@deffn {Directive} {%define extends} "@var{superclass}"
+@deffn {Directive} {%define extends} @{@var{superclass}@}
The superclass of the parser class. Default is none.
@xref{Java Bison Interface}.
@end deffn
@xref{Java Bison Interface}.
@end deffn
-@deffn {Directive} {%define implements} "@var{interfaces}"
+@deffn {Directive} {%define implements} @{@var{interfaces}@}
The implemented interfaces of the parser class, a comma-separated list.
Default is none.
@xref{Java Bison Interface}.
@end deffn
-@deffn {Directive} {%define init_throws} "@var{exceptions}"
+@deffn {Directive} {%define init_throws} @{@var{exceptions}@}
The exceptions thrown by @code{%code init} from the parser class
constructor. Default is none.
@xref{Java Parser Interface}.
@end deffn
-@deffn {Directive} {%define lex_throws} "@var{exceptions}"
+@deffn {Directive} {%define lex_throws} @{@var{exceptions}@}
The exceptions thrown by the @code{yylex} method of the lexer, a
comma-separated list. Default is @code{java.io.IOException}.
@xref{Java Scanner Interface}.
@end deffn
-@deffn {Directive} {%define api.location.type} "@var{class}"
+@deffn {Directive} {%define api.location.type} @{@var{class}@}
The name of the class used for locations (a range between two
positions). This class is generated as an inner class of the parser
class by @command{bison}. Default is @code{Location}.
@xref{Java Location Values}.
@end deffn
-@deffn {Directive} {%define package} "@var{package}"
+@deffn {Directive} {%define package} @{@var{package}@}
The package to put the parser class in. Default is none.
@xref{Java Bison Interface}.
@end deffn
-@deffn {Directive} {%define parser_class_name} "@var{name}"
+@deffn {Directive} {%define parser_class_name} @{@var{name}@}
The name of the parser class. Default is @code{YYParser} or
@code{@var{name-prefix}Parser}.
@xref{Java Bison Interface}.
@end deffn
-@deffn {Directive} {%define api.position.type} "@var{class}"
+@deffn {Directive} {%define api.position.type} @{@var{class}@}
The name of the class used for positions. This class must be supplied by
the user. Default is @code{Position}.
Formerly named @code{position_type}.
@xref{Java Bison Interface}.
@end deffn
-@deffn {Directive} {%define api.value.type} "@var{class}"
+@deffn {Directive} {%define api.value.type} @{@var{class}@}
The base type of semantic values. Default is @code{Object}.
@xref{Java Semantic Values}.
@end deffn
@xref{Java Bison Interface}.
@end deffn
-@deffn {Directive} {%define throws} "@var{exceptions}"
+@deffn {Directive} {%define throws} @{@var{exceptions}@}
The exceptions thrown by user-supplied parser actions and
@code{%initial-action}, a comma-separated list. Default is none.
@xref{Java Parser Interface}.
@deffn {Directive} %define @var{variable}
@deffnx {Directive} %define @var{variable} @var{value}
+@deffnx {Directive} %define @var{variable} @{@var{value}@}
@deffnx {Directive} %define @var{variable} "@var{value}"
Define a variable to adjust Bison's behavior. @xref{%define Summary}.
@end deffn
@code{yypstate_new} and @code{yypstate_delete} will also be renamed. For
example, if you use @samp{%name-prefix "c_"}, the names become
@code{c_parse}, @code{c_lex}, and so on. For C++ parsers, see the
-@code{%define namespace} documentation in this section.
+@code{%define api.namespace} documentation in this section.
@end deffn
projects / bison.git / blobdiff