10. Parsers Written In Other Languages

10.1 C++ Parsers

10.1.1 C++ Bison Interface

The C++ LALR(1) parser is selected using the skeleton directive, `%skeleton "lalr1.c"', or the synonymous command-line option `--skeleton=lalr1.c'. See section Bison Declaration Summary.

When run, bison will create several entities in the `yy' namespace. Use the `%define namespace' directive to change the namespace name, see Bison Declaration Summary. The various classes are generated in the following files:

`position.hh'

`location.hh'

The definition of the classes position and location, used for location tracking. See section C++ Location Values.

`stack.hh'

An auxiliary class stack used by the parser.

`file.hh'

`file.cc'

(Assuming the extension of the input file was `.yy'.) The declaration and implementation of the C++ parser class. The basename and extension of these two files follow the same rules as with regular C parsers (see section Invoking Bison).

The header is mandatory; you must either pass `-d'/`--defines' to bison, or use the `%defines' directive.

All these files are documented using Doxygen; run doxygen for a complete and accurate documentation.

10.1.2 C++ Semantic Values

The %union directive works as for C, see The Collection of Value Types. In particular it produces a genuine union(2), which have a few specific features in C++.

• - The type YYSTYPE is defined but its use is discouraged: rather you should refer to the parser's encapsulated type yy::parser::semantic_type.
• - Non POD (Plain Old Data) types cannot be used. C++ forbids any instance of classes with constructors in unions: only pointers to such objects are allowed.

Because objects have to be stored via pointers, memory is not reclaimed automatically: using the %destructor directive is the only means to avoid leaks. See section Freeing Discarded Symbols.

10.1.3 C++ Location Values

When the directive %locations is used, the C++ parser supports location tracking, see Locations Overview. Two auxiliary classes define a position, a single point in a file, and a location, a range composed of a pair of positions (possibly spanning several files).

Method on position: std::string* file

The name of the file. It will always be handled as a pointer, the parser will never duplicate nor deallocate it. As an experimental feature you may change it to `type*' using `%define filename_type "type"'.

Method on position: unsigned int line

The line, starting at 1.

Method on position: unsigned int lines (int height = 1)

Advance by height lines, resetting the column number.

Method on position: unsigned int column

The column, starting at 0.

Method on position: unsigned int columns (int width = 1)

Advance by width columns, without changing the line number.

Method on position: position& operator+= (position& pos, int width)

Method on position: position operator+ (const position& pos, int width)

Method on position: position& operator-= (const position& pos, int width)

Method on position: position operator- (position& pos, int width)

Various forms of syntactic sugar for columns.

Method on position: position operator<< (std::ostream o, const position& p)

Report p on o like this: `file:line.column', or `line.column' if file is null.

Method on location: position begin

Method on location: position end

The first, inclusive, position of the range, and the first beyond.

Method on location: unsigned int columns (int width = 1)

Method on location: unsigned int lines (int height = 1)

Advance the end position.

Method on location: location operator+ (const location& begin, const location& end)

Method on location: location operator+ (const location& begin, int width)

Method on location: location operator+= (const location& loc, int width)

Various forms of syntactic sugar.

Method on location: void step ()

Move begin onto end.

10.1.4 C++ Parser Interface

The output files `output.hh' and `output.cc' declare and define the parser class in the namespace yy. The class name defaults to parser, but may be changed using `%define parser_class_name "name"'. The interface of this class is detailed below. It can be extended using the %parse-param feature: its semantics is slightly changed since it describes an additional member of the parser class, and an additional argument for its constructor.

Type of parser: semantic_value_type

Type of parser: location_value_type

The types for semantics value and locations.

Method on parser: parser (type1 arg1, ...)

Build a new parser object. There are no arguments by default, unless `%parse-param {type1 arg1}' was used.

Method on parser: int parse ()

Run the syntactic analysis, and return 0 on success, 1 otherwise.

Method on parser: std::ostream& debug_stream ()

Method on parser: void set_debug_stream (std::ostream& o)

Get or set the stream used for tracing the parsing. It defaults to std::cerr.

Method on parser: debug_level_type debug_level ()

Method on parser: void set_debug_level (debug_level l)

Get or set the tracing level. Currently its value is either 0, no trace, or nonzero, full tracing.

Method on parser: void error (const location_type& l, const std::string& m)

The definition for this member function must be supplied by the user: the parser uses it to report a parser error occurring at l, described by m.

10.1.5 C++ Scanner Interface

The parser invokes the scanner by calling yylex. Contrary to C parsers, C++ parsers are always pure: there is no point in using the %define api.pure directive. Therefore the interface is as follows.

Method on parser: int yylex (semantic_value_type& yylval, location_type& yylloc, type1 arg1, ...)

Return the next token. Its type is the return value, its semantic value and location being yylval and yylloc. Invocations of `%lex-param {type1 arg1}' yield additional arguments.

10.1.6 A Complete C++ Example

This section demonstrates the use of a C++ parser with a simple but complete example. This example should be available on your system, ready to compile, in the directory ../bison/examples/calc++. It focuses on the use of Bison, therefore the design of the various C++ classes is very naive: no accessors, no encapsulation of members etc. We will use a Lex scanner, and more precisely, a Flex scanner, to demonstrate the various interaction. A hand written scanner is actually easier to interface with.

10.1.6.1 Calc++ -- C++ Calculator

Of course the grammar is dedicated to arithmetics, a single expression, possibly preceded by variable assignments. An environment containing possibly predefined variables such as one and two, is exchanged with the parser. An example of valid input follows.

three := 3
seven := one + two * three
seven * seven

10.1.6.2 Calc++ Parsing Driver

To support a pure interface with the parser (and the scanner) the technique of the "parsing context" is convenient: a structure containing all the data to exchange. Since, in addition to simply launch the parsing, there are several auxiliary tasks to execute (open the file for parsing, instantiate the parser etc.), we recommend transforming the simple parsing context structure into a fully blown parsing driver class.

The declaration of this driver class, `calc++-driver.hh', is as follows. The first part includes the CPP guard and imports the required standard library components, and the declaration of the parser class.

#ifndef CALCXX_DRIVER_HH
# define CALCXX_DRIVER_HH
# include <string>
# include <map>
# include "calc++-parser.hh"

Then comes the declaration of the scanning function. Flex expects the signature of yylex to be defined in the macro YY_DECL, and the C++ parser expects it to be declared. We can factor both as follows.

// Tell Flex the lexer's prototype ...
# define YY_DECL                                        \
  yy::calcxx_parser::token_type                         \
  yylex (yy::calcxx_parser::semantic_type* yylval,      \
         yy::calcxx_parser::location_type* yylloc,      \
         calcxx_driver& driver)
// ... and declare it for the parser's sake.
YY_DECL;

The calcxx_driver class is then declared with its most obvious members.

// Conducting the whole scanning and parsing of Calc++.
class calcxx_driver
{
public:
  calcxx_driver ();
  virtual ~calcxx_driver ();

  std::map<std::string, int> variables;

  int result;

To encapsulate the coordination with the Flex scanner, it is useful to have two members function to open and close the scanning phase.

  // Handling the scanner.
  void scan_begin ();
  void scan_end ();
  bool trace_scanning;

Similarly for the parser itself.

  // Run the parser.  Return 0 on success.
  int parse (const std::string& f);
  std::string file;
  bool trace_parsing;

To demonstrate pure handling of parse errors, instead of simply dumping them on the standard error output, we will pass them to the compiler driver using the following two member functions. Finally, we close the class declaration and CPP guard.

  // Error handling.
  void error (const yy::location& l, const std::string& m);
  void error (const std::string& m);
};
#endif // ! CALCXX_DRIVER_HH

The implementation of the driver is straightforward. The parse member function deserves some attention. The error functions are simple stubs, they should actually register the located error messages and set error state.

#include "calc++-driver.hh"
#include "calc++-parser.hh"

calcxx_driver::calcxx_driver ()
  : trace_scanning (false), trace_parsing (false)
{
  variables["one"] = 1;
  variables["two"] = 2;
}

calcxx_driver::~calcxx_driver ()
{
}

int
calcxx_driver::parse (const std::string &f)
{
  file = f;
  scan_begin ();
  yy::calcxx_parser parser (*this);
  parser.set_debug_level (trace_parsing);
  int res = parser.parse ();
  scan_end ();
  return res;
}

void
calcxx_driver::error (const yy::location& l, const std::string& m)
{
  std::cerr << l << ": " << m << std::endl;
}

void
calcxx_driver::error (const std::string& m)
{
  std::cerr << m << std::endl;
}

10.1.6.3 Calc++ Parser

The parser definition file `calc++-parser.yy' starts by asking for the C++ LALR(1) skeleton, the creation of the parser header file, and specifies the name of the parser class. Because the C++ skeleton changed several times, it is safer to require the version you designed the grammar for.

%skeleton "lalr1.cc"                          /*  -*- C++ -*- */
%require "2.4.1"
%defines
%define parser_class_name "calcxx_parser"

Then come the declarations/inclusions needed to define the %union. Because the parser uses the parsing driver and reciprocally, both cannot include the header of the other. Because the driver's header needs detailed knowledge about the parser class (in particular its inner types), it is the parser's header which will simply use a forward declaration of the driver. See section %code.

%code requires {
# include <string>
class calcxx_driver;
}

The driver is passed by reference to the parser and to the scanner. This provides a simple but effective pure interface, not relying on global variables.

// The parsing context.
%parse-param { calcxx_driver& driver }
%lex-param   { calcxx_driver& driver }

Then we request the location tracking feature, and initialize the first location's file name. Afterwards new locations are computed relatively to the previous locations: the file name will be automatically propagated.

%locations
%initial-action
{
  // Initialize the initial location.
  @$.begin.filename = @$.end.filename = &driver.file;
};

Use the two following directives to enable parser tracing and verbose error messages.

%debug
%error-verbose

Semantic values cannot use "real" objects, but only pointers to them.

// Symbols.
%union
{
  int          ival;
  std::string *sval;
};

The code between `%code {' and `}' is output in the `*.cc' file; it needs detailed knowledge about the driver.

%code {
# include "calc++-driver.hh"
}

The token numbered as 0 corresponds to end of file; the following line allows for nicer error messages referring to "end of file" instead of "$end". Similarly user friendly named are provided for each symbol. Note that the tokens names are prefixed by TOKEN_ to avoid name clashes.

%token        END      0 "end of file"
%token        ASSIGN     ":="
%token <sval> IDENTIFIER "identifier"
%token <ival> NUMBER     "number"
%type  <ival> exp

To enable memory deallocation during error recovery, use %destructor.

%printer    { debug_stream () << *$$; } "identifier"
%destructor { delete $$; } "identifier"

%printer    { debug_stream () << $$; } <ival>

The grammar itself is straightforward.

%%
%start unit;
unit: assignments exp  { driver.result = $2; };

assignments: assignments assignment {}
           | /* Nothing.  */        {};

assignment:
     "identifier" ":=" exp
       { driver.variables[*$1] = $3; delete $1; };

%left '+' '-';
%left '*' '/';
exp: exp '+' exp   { $$ = $1 + $3; }
   | exp '-' exp   { $$ = $1 - $3; }
   | exp '*' exp   { $$ = $1 * $3; }
   | exp '/' exp   { $$ = $1 / $3; }
   | "identifier"  { $$ = driver.variables[*$1]; delete $1; }
   | "number"      { $$ = $1; };
%%

Finally the error member function registers the errors to the driver.

void
yy::calcxx_parser::error (const yy::calcxx_parser::location_type& l,
                          const std::string& m)
{
  driver.error (l, m);
}

10.1.6.4 Calc++ Scanner

The Flex scanner first includes the driver declaration, then the parser's to get the set of defined tokens.

%{                                            /* -*- C++ -*- */
# include <cstdlib>
# include <errno.h>
# include <limits.h>
# include <string>
# include "calc++-driver.hh"
# include "calc++-parser.hh"

/* Work around an incompatibility in flex (at least versions
   2.5.31 through 2.5.33): it generates code that does
   not conform to C89.  See Debian bug 333231
   <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333231>.  */
# undef yywrap
# define yywrap() 1

/* By default yylex returns int, we use token_type.
   Unfortunately yyterminate by default returns 0, which is
   not of token_type.  */
#define yyterminate() return token::END
%}

Because there is no #include-like feature we don't need yywrap, we don't need unput either, and we parse an actual file, this is not an interactive session with the user. Finally we enable the scanner tracing features.

%option noyywrap nounput batch debug

Abbreviations allow for more readable rules.

id    [a-zA-Z][a-zA-Z_0-9]*
int   [0-9]+
blank [ \t]

The following paragraph suffices to track locations accurately. Each time yylex is invoked, the begin position is moved onto the end position. Then when a pattern is matched, the end position is advanced of its width. In case it matched ends of lines, the end cursor is adjusted, and each time blanks are matched, the begin cursor is moved onto the end cursor to effectively ignore the blanks preceding tokens. Comments would be treated equally.

%{
# define YY_USER_ACTION  yylloc->columns (yyleng);
%}
%%
%{
  yylloc->step ();
%}
{blank}+   yylloc->step ();
[\n]+      yylloc->lines (yyleng); yylloc->step ();

The rules are simple, just note the use of the driver to report errors. It is convenient to use a typedef to shorten yy::calcxx_parser::token::identifier into token::identifier for instance.

%{
  typedef yy::calcxx_parser::token token;
%}
           /* Convert ints to the actual type of tokens.  */
[-+*/]     return yy::calcxx_parser::token_type (yytext[0]);
":="       return token::ASSIGN;
{int}      {
  errno = 0;
  long n = strtol (yytext, NULL, 10);
  if (! (INT_MIN <= n && n <= INT_MAX && errno != ERANGE))
    driver.error (*yylloc, "integer is out of range");
  yylval->ival = n;
  return token::NUMBER;
}
{id}       yylval->sval = new std::string (yytext); return token::IDENTIFIER;
.          driver.error (*yylloc, "invalid character");
%%

Finally, because the scanner related driver's member function depend on the scanner's data, it is simpler to implement them in this file.

void
calcxx_driver::scan_begin ()
{
  yy_flex_debug = trace_scanning;
  if (file == "-")
    yyin = stdin;
  else if (!(yyin = fopen (file.c_str (), "r")))
    {
      error (std::string ("cannot open ") + file);
      exit (1);
    }
}

void
calcxx_driver::scan_end ()
{
  fclose (yyin);
}

10.1.6.5 Calc++ Top Level

The top level file, `calc++.cc', poses no problem.

#include <iostream>
#include "calc++-driver.hh"

int
main (int argc, char *argv[])
{
  calcxx_driver driver;
  for (++argv; argv[0]; ++argv)
    if (*argv == std::string ("-p"))
      driver.trace_parsing = true;
    else if (*argv == std::string ("-s"))
      driver.trace_scanning = true;
    else if (!driver.parse (*argv))
      std::cout << driver.result << std::endl;
}

10.2 Java Parsers

10.2.1 Java Bison Interface

(The current Java interface is experimental and may evolve. More user feedback will help to stabilize it.)

The Java parser skeletons are selected using the %language "Java" directive or the `-L java'/`--language=java' option.

When generating a Java parser, bison basename.y will create a single Java source file named `basename.java'. Using an input file without a `.y' suffix is currently broken. The basename of the output file can be changed by the %file-prefix directive or the `-p'/`--name-prefix' option. The entire output file name can be changed by the %output directive or the `-o'/`--output' option. The output file contains a single class for the parser.

You can create documentation for generated parsers using Javadoc.

Contrary to C parsers, Java parsers do not use global variables; the state of the parser is always local to an instance of the parser class. Therefore, all Java parsers are "pure", and the %pure-parser and %define api.pure directives does not do anything when used in Java.

Push parsers are currently unsupported in Java and %define api.push_pull have no effect.

GLR parsers are currently unsupported in Java. Do not use the glr-parser directive.

No header file can be generated for Java parsers. Do not use the %defines directive or the `-d'/`--defines' options.

Currently, support for debugging and verbose errors are always compiled in. Thus the %debug and %token-table directives and the `-t'/`--debug' and `-k'/`--token-table' options have no effect. This may change in the future to eliminate unused code in the generated parser, so use %debug and %verbose-error explicitly if needed. Also, in the future the %token-table directive might enable a public interface to access the token names and codes.

10.2.2 Java Semantic Values

There is no %union directive in Java parsers. Instead, the semantic values' types (class names) should be specified in the %type or %token directive:

%type <Expression> expr assignment_expr term factor
%type <Integer> number

By default, the semantic stack is declared to have Object members, which means that the class types you specify can be of any class. To improve the type safety of the parser, you can declare the common superclass of all the semantic values using the %define stype directive. For example, after the following declaration:

%define stype "ASTNode"

any %type or %token specifying a semantic type which is not a subclass of ASTNode, will cause a compile-time error.

Types used in the directives may be qualified with a package name. Primitive data types are accepted for Java version 1.5 or later. Note that in this case the autoboxing feature of Java 1.5 will be used. Generic types may not be used; this is due to a limitation in the implementation of Bison, and may change in future releases.

Java parsers do not support %destructor, since the language adopts garbage collection. The parser will try to hold references to semantic values for as little time as needed.

Java parsers do not support %printer, as toString() can be used to print the semantic values. This however may change (in a backwards-compatible way) in future versions of Bison.

10.2.3 Java Location Values

When the directive %locations is used, the Java parser supports location tracking, see Locations Overview. An auxiliary user-defined class defines a position, a single point in a file; Bison itself defines a class representing a 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 Location by default, and may also be renamed using %define location_type "class-name.

The location class treats the position as a completely opaque value. By default, the class name is Position, but this can be changed with %define position_type "class-name". This class must be supplied by the user.

Instance Variable of Location: Position begin

Instance Variable of Location: Position end

The first, inclusive, position of the range, and the first beyond.

Constructor on Location: Location (Position loc)

Create a Location denoting an empty range located at a given point.

Constructor on Location: Location (Position begin, Position end)

Create a Location from the endpoints of the range.

Method on Location: String toString ()

Prints the range represented by the location. For this to work properly, the position class should override the equals and toString methods appropriately.

10.2.4 Java Parser Interface

The name of the generated parser class defaults to YYParser. The YY prefix may be changed using the %name-prefix directive or the `-p'/`--name-prefix' option. Alternatively, use %define parser_class_name "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 %define public will change to public visibility. Remember that, according to the Java language specification, the name of the `.java' file should match the name of the class in this case. Similarly, you can use abstract, final and strictfp with the %define declaration to add other modifiers to the parser class.

The Java package name of the parser class can be specified using the %define package directive. The superclass and the implemented interfaces of the parser class can be specified with the %define extends and %define implements directives.

The parser class defines an inner class, Location, that is used for location tracking (see Java Location Values), and a inner interface, Lexer (see Java Scanner Interface). Other than these inner class/interface, and the members described in the interface below, all the other members and fields are preceded with a yy or YY prefix to avoid clashes with user code.

The parser class can be extended using the %parse-param directive. Each occurrence of the directive will add a protected final field to the parser class, and an argument to its constructor, which initialize them automatically.

Token names defined by %token and the predefined EOF token name are added as constant fields to the parser class.

Constructor on YYParser: YYParser (lex_param, …, parse_param, …)

Build a new parser object with embedded %code lexer. There are no parameters, unless %parse-params and/or %lex-params are used.

Constructor on YYParser: YYParser (Lexer lexer, parse_param, …)

Build a new parser object using the specified scanner. There are no additional parameters unless %parse-params are used.

If the scanner is defined by %code lexer, this constructor is declared protected and is called automatically with a scanner created with the correct %lex-params.

Method on YYParser: boolean parse ()

Run the syntactic analysis, and return true on success, false otherwise.

Method on YYParser: boolean recovering ()

During the syntactic analysis, return true if recovering from a syntax error. See section Error Recovery.

Method on YYParser: java.io.PrintStream getDebugStream ()

Method on YYParser: void setDebugStream (java.io.printStream o)

Get or set the stream used for tracing the parsing. It defaults to System.err.

Method on YYParser: int getDebugLevel ()

Method on YYParser: void setDebugLevel (int l)

Get or set the tracing level. Currently its value is either 0, no trace, or nonzero, full tracing.

10.2.5 Java Scanner Interface

There are two possible ways to interface a Bison-generated Java parser with a scanner: the scanner may be defined by %code lexer, or defined elsewhere. In either case, the scanner has to implement the Lexer inner interface of the parser class.

In the first case, the body of the scanner class is placed in %code lexer blocks. If you want to pass parameters from the parser constructor to the scanner constructor, specify them with %lex-param; they are passed before %parse-params to the constructor.

In the second case, the scanner has to implement the Lexer interface, which is defined within the parser class (e.g., YYParser.Lexer). The constructor of the parser object will then accept an object implementing the interface; %lex-param is not used in this case.

In both cases, the scanner has to implement the following methods.

Method on Lexer: void yyerror (Location loc, String 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 %define location_type "class-name".

Method on Lexer: int yylex ()

Return the next token. Its type is the return value, its semantic value and location are saved and returned by the ther methods in the interface.

Use %define lex_throws to specify any uncaught exceptions. Default is java.io.IOException.

Method on Lexer: Position getStartPos ()

Method on Lexer: Position getEndPos ()

Return respectively the first position of the last token that yylex returned, and the first position beyond it. These methods are not needed unless location tracking is active.

The return type can be changed using %define position_type "class-name".

Method on Lexer: Object getLVal ()

Return the semantical value of the last token that yylex returned.

The return type can be changed using %define stype "class-name".

10.2.6 Special Features for Use in Java Actions

The following special constructs can be uses in Java actions. Other analogous C action features are currently unavailable for Java.

Use %define throws to specify any uncaught exceptions from parser actions, and initial actions specified by %initial-action.

Variable: $n

The semantic value for the nth component of the current rule. This may not be assigned to. See section Java Semantic Values.

Variable: $<typealt>n

Like $n but specifies a alternative type typealt. See section Java Semantic Values.

Variable: $$

The semantic value for the grouping made by the current rule. As a value, this is in the base type (Object or as specified by %define stype) as in not cast to the declared subtype because casts are not allowed on the left-hand side of Java assignments. Use an explicit Java cast if the correct subtype is needed. See section Java Semantic Values.

Variable: $<typealt>$

Same as $$ since Java always allow assigning to the base type. Perhaps we should use this and $<>$ for the value and $$ for setting the value but there is currently no easy way to distinguish these constructs. See section Java Semantic Values.

Variable: @n

The location information of the nth component of the current rule. This may not be assigned to. See section Java Location Values.

Variable: @$

The location information of the grouping made by the current rule. See section Java Location Values.

Statement: return YYABORT;

Return immediately from the parser, indicating failure. See section Java Parser Interface.

Statement: return YYACCEPT;

Return immediately from the parser, indicating success. See section Java Parser Interface.

Statement: return YYERROR;

Start error recovery without printing an error message. See section Error Recovery.

Statement: return YYFAIL;

Print an error message and start error recovery. See section Error Recovery.

Function: boolean recovering ()

Return whether error recovery is being done. In this state, the parser reads token until it reaches a known state, and then restarts normal operation. See section Error Recovery.

Function: protected void yyerror (String msg)

Function: protected void yyerror (Position pos, String msg)

Function: protected void yyerror (Location loc, String msg)

Print an error message using the yyerror method of the scanner instance in use.

10.2.7 Differences between C/C++ and Java Grammars

The different structure of the Java language forces several differences between C/C++ grammars, and grammars designed for Java parsers. This section summarizes these differences.

• Java lacks a preprocessor, so the YYERROR, YYACCEPT, YYABORT symbols (see section Bison Symbols) cannot obviously be macros. Instead, they should be preceded by return when they appear in an action. The actual definition of these symbols is opaque to the Bison grammar, and it might change in the future. The only meaningful operation that you can do, is to return them. See see section Special Features for Use in Java Actions.

  Note that of these three symbols, only YYACCEPT and YYABORT will cause a return from the yyparse method(3).

• Java lacks unions, so %union has no effect. Instead, semantic values have a common base type: Object or as specified by %define stype. Angle backets on %token, type, $n and $$ specify subtypes rather than fields of an union. The type of $$, even with angle brackets, is the base type since Java casts are not allow on the left-hand side of assignments. Also, $n and @n are not allowed on the left-hand side of assignments. See see section Java Semantic Values and see section Special Features for Use in Java Actions.
• The prolog declarations have a different meaning than in C/C++ code.

  %code imports

  blocks are placed at the beginning of the Java source code. They may include copyright notices. For a package declarations, it is suggested to use %define package instead.

  unqualified %code

  blocks are placed inside the parser class.

  %code lexer

  blocks, if specified, should include the implementation of the scanner. If there is no such block, the scanner can be any class that implements the appropriate interface (see see section Java Scanner Interface).

  Other %code blocks are not supported in Java parsers. In particular, %{ … %} blocks should not be used and may give an error in future versions of Bison.

  The epilogue has the same meaning as in C/C++ code and it can be used to define other classes used by the parser outside the parser class.

10.2.8 Java Declarations Summary

This summary only include declarations specific to Java or have special meaning when used in a Java parser.

Directive: %language "Java"

Generate a Java class for the parser.

Directive: %lex-param {type name}

A parameter for the lexer class defined by %code lexer only, added as parameters to the lexer constructor and the parser constructor that creates a lexer. Default is none. See section Java Scanner Interface.

Directive: %name-prefix "prefix"

The prefix of the parser class name prefixParser if %define parser_class_name is not used. Default is YY. See section Java Bison Interface.

Directive: %parse-param {type name}

A parameter for the parser class added as parameters to constructor(s) and as fields initialized by the constructor(s). Default is none. See section Java Parser Interface.

Directive: %token <type> token …

Declare tokens. Note that the angle brackets enclose a Java type. See section Java Semantic Values.

Directive: %type <type> nonterminal …

Declare the type of nonterminals. Note that the angle brackets enclose a Java type. See section Java Semantic Values.

Directive: %code { code … }

Code appended to the inside of the parser class. See section Differences between C/C++ and Java Grammars.

Directive: %code imports { code … }

Code inserted just after the package declaration. See section Differences between C/C++ and Java Grammars.

Directive: %code lexer { code … }

Code added to the body of a inner lexer class within the parser class. See section Java Scanner Interface.

Directive: %% code …

Code (after the second %%) appended to the end of the file, outside the parser class. See section Differences between C/C++ and Java Grammars.

Directive: %{ code … %}

Not supported. Use %code import instead. See section Differences between C/C++ and Java Grammars.

Directive: %define abstract

Whether the parser class is declared abstract. Default is false. See section Java Bison Interface.

Directive: %define extends "superclass"

The superclass of the parser class. Default is none. See section Java Bison Interface.

Directive: %define final

Whether the parser class is declared final. Default is false. See section Java Bison Interface.

Directive: %define implements "interfaces"

The implemented interfaces of the parser class, a comma-separated list. Default is none. See section Java Bison Interface.

Directive: %define lex_throws "exceptions"

The exceptions thrown by the yylex method of the lexer, a comma-separated list. Default is java.io.IOException. See section Java Scanner Interface.

Directive: %define location_type "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 bison. Default is Location. See section Java Location Values.

Directive: %define package "package"

The package to put the parser class in. Default is none. See section Java Bison Interface.

Directive: %define parser_class_name "name"

The name of the parser class. Default is YYParser or name-prefixParser. See section Java Bison Interface.

Directive: %define position_type "class"

The name of the class used for positions. This class must be supplied by the user. Default is Position. See section Java Location Values.

Directive: %define public

Whether the parser class is declared public. Default is false. See section Java Bison Interface.

Directive: %define stype "class"

The base type of semantic values. Default is Object. See section Java Semantic Values.

Directive: %define strictfp

Whether the parser class is declared strictfp. Default is false. See section Java Bison Interface.

Directive: %define throws "exceptions"

The exceptions thrown by user-supplied parser actions and %initial-action, a comma-separated list. Default is none. See section Java Parser Interface.

This document was generated on February, 15 2009 using texi2html 1.76.