Commits (249)

Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.

block atdollar
firstset element
symbol firstset
terminal symbol
production block terminal
nonterminal production
symtab nonterminal
rules nonterminal
grammar rules
lookaheadset grammar
item lookaheadset
rrdata lookaheadset
stateitem item rrdata rmshift rmreduction
rrconflict stateitem
next enumsolution statetype stateitem
srconflict next
state srconflict rrconflict
writer state
scanner block options
generator writer options
parser scanner rules symtab
To Install bisonc++ by hand instead of using the binary distribution perform
the following steps:
0. Bisonc++ and its construction depends, in addition to the normally
standard available system software on specific software and versions
which is documented in the file `required', in particular the Bobcat
(If you compile the bobcat library yourself, note that bisonc++ does
not use the SSL, Milter and Xpointer classes; they may --as far as
bisonc++ is concerned-- be left out of the library)
1. To install bobcat icmake should be used, for which a top-level script
(build) and support scripts in the ./icmake/ directory are
available. Icmake is available on many architectures.
2. Inspect the values of the variables in the file INSTALL.im, in
particular the #defines below COMPONENTS TO INSTALL. Modify
these #defines when necessary.
3. Inspect the path to icmake at the top of the `build' script. By default
it is /usr/bin/icmake, but some installations use
/usr/local/bin/icmake Adapt when necessary.
4. Run
./build program [strip]
to compile bisonc++. The argument `strip' is optional and strips
symbolic information from the final executable.
5. If you installed Yodl then you can create the documentation:
./build man
builds the man-pages, and
./build manual
builds the manual.
6. Run (probably as root)
./build install 'LOG:path' 'what' 'base'
to install components of Bisonc++.
'LOG:path' is an optional item specifying the absolute or relative
path of a log file to contain a log of all installed files (see
also the next item). Using LOG:~/.bisoncpp usually works
well. Do not put any blanks between LOG: and the path
specification, or protect the LOG: specification by quotes.
'what' specifies what you want to install.
x, to install all components,
or specify a combination of:
a (additional documentation),
b (binary program),
d (standard documentation),
m (man-pages)
s (skeleton files)
u (user guide)
E.g., use
./build install bs 'base'
if you only want to be able to run bisonc++, and want it to be
installed below 'base'.
When requesting non-existing elements (e.g., ./build install x
was requested, but the man-pages weren't constructed) then
these non-existing elements are silently ignored by the
installation process.
'base' is optional and specifies the base directory below which
the requested files are installed. This base directory is
prepended to the paths #defined in the INSTALL.im file. If
'base' is not specified, then INSTALL.im's #defined paths are
used as-is.
7. Uninstalling previously installed components of Bisonc++ is easy if a
log path (LOG:...) was specified at the `./build install ...'
command. In that case, run the command
./build uninstall logpath
where 'logpath' specifies the location of the logfile that was
written by ./build install. Modified files and non-empty directories
are not removed, but the logfile itself is removed following the
8. Following the installation nothing in the directory tree which contains
this file (i.e., INSTALL) is required for the proper functioning of
bisonc++, so consider removing it. If you only want to remove
left-over files from the build-process, just run
./build distclean
NOTE: the parser-class header file generated by bisonc++ before version
4.02.00 should have the prototypes of some of their private members
Simply replacing the `support functions for parse()' section shown at the
end of the header file by the following lines should make your header
file up-to-date again. Bisonc++ will not by itself rewrite the
parser class headers to prevent undoing any modifications you may have
implemented in parser-class header files:
// support functions for parse():
void executeAction(int ruleNr);
void errorRecovery();
int lookup(bool recovery);
void nextToken();
void print_();
void exceptionHandler_(std::exception const &exc);
The function print_) is defined by bisonc++, the default implementation
of exceptionHandler_() can be added to the parser's internal header
inline void Parser::exceptionHandler_(std::exception const &exc)
throw; // optionally re-implement to handle exceptions thrown
// by actions
// The name of the program and the support directories as installed by
// the 'build install' command. Normally there is no reason for changing
// this #define
#define PROGRAM "bisonc++"
// The following /bin/cp option is used to keep, rather than follow
// symbolic references. If your installation doesn't support these flags,
// then change them into available ones.
// -P, --no-dereference
// never follow symbolic links in SOURCE
// --preserve[=ATTR_LIST]
// preserve the specified attributes (default:
// mode,ownership,timestamps), if possible additional
// attributes: context, links, all
// -d same as --no-dereference --preserve=links
#define CPOPTS "-d"
// The CXX, CXXFLAGS, and LDFLAGS #defines are overruled by identically
// named environment variables:
#define GNU
#ifdef GNU
#define CXX "g++"
#define CXXFLAGS "--std=c++2a -Wall -O2 -pthread " \
#define CXX "clang++"
// #define CXXFLAGS "-fmodules --std=c++2a -Wall -O2 -pthread " \
// "-fdiagnostics-color=never"
#define CXXFLAGS "--std=c++2a -Wall -O2 -pthread " \
// "-Wunused-parameter -Werror"
#define LDFLAGS ""
// flags passed to the linker
// =====================
// For an operational non-Debian installation, you probably must be
// `root'.
// If necessary, adapt the #defines below to your situation.
// The provided locations are used by Debian Linux.
// With 'build install' you can dynamically specify a location to prepend
// to the locations configured here, and select which components you want
// to install
// the directory where additional documentation is stored
#define ADD "/usr/share/doc/"${PROGRAM}"-doc"
// the full pathname of the final program
#define BINARY "/usr/bin/"${PROGRAM}
// the directory where the standard documentation is stored
#define DOC "/usr/share/doc/"${PROGRAM}
// the directory below where the man pages are stored
#define MAN "/usr/share/man"
// the directory whre the user-guide is stored
#define UGUIDE "/usr/share/doc/"${PROGRAM}"-doc/manual"
// the directory where the skeleton files are installed
// Recompile options/data.cc if the skeleton location changes
#define SKEL "/usr/share/bisonc++"
This diff is collapsed.
Bisonc++ 0.98 is a complete rewrite of the well-known bison(++) parser
generator. See the manual page for details.
Several demo programs are found below the bisonc++/documentation/examples
directory. In that directory there's a README file describing the purposes of
the various examples.
The (original) bison documentation is provided in html format in the directory
bisonc++/documentation/html. The Debian package (bisonc++*.deb) installs that
documentation below /usr/share/doc/bisonc++.
Note that bisonc++'s specifications differs from bison's specifications, in
particular with respect to the declaration section. The production rule
specification section is, however, practically identical to the one defined
for bison. There are some differences, though. Consult bisonc++'s manpage
(installed by the Debian package, otherwise available in the directory
bisonc++/documentation/man) for the differences.
Since it is a complete rewrite it is quite likely that bugs will be
encountered. Bison itself offers an extensive input grammar, and I may easily
have overlooked various subtleties.
Do not hesitate to contact me when you encounter a bug. A (small) grammar
illustrating your point is then always extremely useful.
May 2005-April 2006
This hierarchy defines the header and the implementation dependencies among
the classes. The topmost class is not dependent on any class. Lines should be
read down-to-up to find the the lowest class in the hierarchy on which a
given class depends (e.g., LookaheadSet depends on Grammar, and possibly uses
the classes used by Grammar; RmReduction does not depend on any other class).
AtDollar Element
| |
Block FirstSet
| |
+-------+ Symbol
| | |
| | Terminal
| | |
| +---------------+
| |
| Production
| |
| NonTerminal
| |
| +---------------+
| | |
| Symtab Rules
| | |
| +--------+------+
| | |
| | Grammar
| | |
| | LookaheadSet
| | |
| | +-----------+
| | | |
| | Item RRData RmShift RmReduction
| | | | | |
| | +-----------+-----------+-----------+
| | |
| | EnumSolution StateType StateItem
| | | | |
| | | | +--+
| | | | | |
| | +---------------+---------------+ |
| | | |
| | Next |
| | | |
| Options | SrConflict RRConflict
| | | | |
| | | +------------------+
| | | |
| +----------- | --------+ State
| | | | |
+---+ | | Writer
| | | |
Scanner | +----------------+
| | |
+----------------+ |
| |
Parser Generator
| |
About the lexical scanner
Bisonc++ uses a lexical scanner generated by flex.
The file bisonc++/scanner/yylex.cc depends on a file FlexLexer.h having
different contents over different `flex' versions.
Bisonc++ therefore also depends on flex being installed, callable as the
program `flex'.
Starting with Bisonc++ version 2.4.2 the build process will create
scanner/yylex.cc from the file scanner/lexer and scanner/yylex.cc is no longer
included in Bisonc++'s distribution.
\ No newline at end of file
Classes Item, Next, NonTerminal, StateItem and Terminal use a static
inserter() function to define the way the object is inserted into a
stream. These functions expect addresses of member functions defining a
particular insertion as their arguments.
In the class header files the members that define an insertion type are listed
immediately following the inserter() prototype.
Currently only the Terminal class supports a manipulator functionality for
these member functions, allowing a insertion mode-switch within a single
insertion statement.
The algorithm that is used to compute the look-ahead sets of all items of all
states of a grammar is described in chapter 7 (The Bisonc++ Parser Algorithm)
of Bisonc++'s user mannual, as well as in the state/determinelasets.cc source
file. Please refer to these documentation sources for further information
about the LA sets computation algorithm.
Output to the xxx.output file by the --verbose or --construction flags are
mostly handled from the State::allStates() function. This function calls
State's operator<<, which is initialized by a pointer pointing to either
Inspect state/insertstd.cc for the standard insertion method and
state/insertext.cc for the extensive insertion method.
Bisonc++ 2.0.0 uses a grammar specification file (parser/grammar) defining the
input language that it will recognize. The grammar specification file was
initially written to be used with Bisonc++ 1.6.1, but once Bisonc++ 2.0.0 was
available it was split into various subfiles, each having a well defined
function. As a result, the individual grammar specification files are fairly
small, which facilitates understanding of the grammar.
The main grammar specification file is the file parser/grammar, the
subdirectory parser/spec contains the grammar specification subfiles:
A short file, defining tokens, the semantic value union, the grammar's
start rule and one support rule used by the start rule.
Defines all rules that expect a token and assign an appropriate text
to the syntactic error message variable `d_msg'. All these rules end in
_t. Another set of rules (ending in _m) merely set the `d_msg' data
Defines support rules when recognizing the precedence (LEFT, RIGHT,
NONASSOC) and TOKEN terminals directives. These rules end in _p.
Defines rules for all tokens that may optionally be given. These rules
all start with the phrase `opt'.
Defines the syntax for each of Bisonc++'s directives.
All precedence directives, the %token directive and the %type
directive all expect one or more symbols. The `symbols' rule is defined in
this file.
Defines the grammar recognizing Bisonc++'s rules
Defines the grammar recognizing the production rules recognized by
Defines rules that are used in at least two specification files. These
rules all end in _a.
A short demo program is found in documentation/manual/grammar/poly/;
A demo illustrating the way polymorphic semantic type assignment works is
provided in documentation/manual/grammar/essence/demo.cc.
enum class Tag_
defines the tags that are associated with the various semantic value
types. Examples of tags:
namespace Meta_
1. defines struct templates TagOf that, when provided with the actual data
types, provide the associated Tag_ as
template <>
struct TagOf<FlexTypes::TextType>
static Tag_ const tag = Tag_::TEXTTYPE;
2. defines struct templates TypeOf that, when provided with a tag,
provides the associated data type as
typename TypeOf<Tag_>::type
template <>
struct TypeOf<Tag_::VECTOR>
typedef std::vector<std::string> type;
%polymorphic and %union support tag/field checks. Correct type assignments for
missing rules is checked in parser/handleproductionelement.cc and
See also parser/indextooffset.cc for a description how $-indices are converted
to offsets.
Class organization and inner working of polymorphic values
During a short time interval the Meta_ class Base implemented polymorphic
behavior without using virtual members. Although this is possible, it also
results in a somewhat artificial implementation, as C++ offers a clean
definition and implentation of polymorphism. Therefore, shortly after
releasing bisonc++ 5.00.00 bisonc++ now generates a standard polymorphic
implementation of the class Meta_::Base.
The class Meta_::Base has the following interface:
class Base
Tag_ d_baseTag; // The tag is assigned by Semantic.
Base(Base const &other) = delete;
virtual ~Base();
Tag_ tag() const;
Base *clone() const;
void *data() const;
virtual void *vData() const;
virtual Base *vClone() const;
Base is used as Semantic<Tag_> class template's base class, where the various