We are very happy to announce the release of Bison 3.2.90, a beta of Bison 3.3. Please, use it, stress it, and report results.
It is now possible to annotate rules with their number of expected conflicts. Bison can be made relocatable. The symbol declaration syntax was overhauled, and in particular, %nterm, that exists since the origins of Bison, is now an officially supported (and documented!) feature. C++ parsers now feature genuine symbol constructors, and use noexcept/constexpr. The GLR parsers in C++ now also support the syntax_error exceptions. There are also many smaller improvements, including a fix for a bug which is at least 31 years old. Please see the NEWS below for more details. ================================================================== Bison is a general-purpose parser generator that converts an annotated context-free grammar into a deterministic LR or generalized LR (GLR) parser employing LALR(1) parser tables. Bison can also generate IELR(1) or canonical LR(1) parser tables. Once you are proficient with Bison, you can use it to develop a wide range of language parsers, from those used in simple desk calculators to complex programming languages. Bison is upward compatible with Yacc: all properly-written Yacc grammars ought to work with Bison with no change. Anyone familiar with Yacc should be able to use Bison with little trouble. You need to be fluent in C or C++ programming in order to use Bison. Java is also supported. Here is the GNU Bison home page: https://gnu.org/software/bison/ ================================================================== Here are the compressed sources: https://alpha.gnu.org/gnu/bison/bison-3.2.90.tar.gz (4.1MB) https://alpha.gnu.org/gnu/bison/bison-3.2.90.tar.xz (2.1MB) Here are the GPG detached signatures[*]: https://alpha.gnu.org/gnu/bison/bison-3.2.90.tar.gz.sig https://alpha.gnu.org/gnu/bison/bison-3.2.90.tar.xz.sig Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify bison-3.2.90.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys 0DDCAA3278D5264E and rerun the 'gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.69 Automake 1.16.1 Flex 2.6.4 Gettext 0.19.8.1 Gnulib v0.1-2353-g315eb5ffc NEWS * 🎉 Noteworthy changes in release 3.2.90 (2019-01-12) [beta] ** ☠️ Backward incompatible changes Support for DJGPP, which has been unmaintained and untested for years, is removed. ** ⚰️️ Deprecated features The %error-verbose directive is deprecated in favor of '%define parse.error verbose' since Bison 3.0, but no warning was issued. The '%name-prefix "xx"' directive is deprecated in favor of '%define api.prefix {xx}' since Bison 3.0, but no warning was issued. These directives are slightly different, you might need to adjust your code. %name-prefix renames only symbols with external linkage, while api.prefix also renames types and macros, including @code{YYDEBUG}, @code{YYTOKENTYPE}, @code{yytokentype}, @code{YYSTYPE}, @code{YYLTYPE}, etc. The following variables, mostly related to parsers in Java, have been renamed for consistency. Backward compatibility is ensured, but upgrading is recommended. abstract -> api.parser.abstract annotations -> api.parser.annotations extends -> api.parser.extends final -> api.parser.final implements -> api.parser.implements parser_class_name -> api.parser.class public -> api.parser.public strictfp -> api.parser.strictfp ** ✨ New features *** ✨ Bison is now relocatable If you pass '--enable-relocatable' to 'configure', Bison is relocatable. A relocatable program can be moved or copied to a different location on the file system. It can also be used through mount points for network sharing. It is possible to make symlinks to the installed and moved programs, and invoke them through the symlink. *** ✨ %expect and %expect-rr modifiers on individual rules One can now document (and check) which rules participate in shift/reduce and reduce/reduce conflicts. This is particularly important GLR parsers, where conflicts are a normal occurrence. For example, %glr-parser %expect 1 %% ... argument_list: arguments %expect 1 | arguments ',' | %empty ; arguments: expression | argument_list ',' expression ; ... Looking at the output from -v, one can see that the shift-reduce conflict here is due to the fact that the parser does not know whether to reduce arguments to argument_list until it sees the token _after_ the following ','. By marking the rule with %expect 1 (because there is a conflict in one state), we document the source of the 1 overall shift-reduce conflict. In GLR parsers, we can use %expect-rr in a rule for reduce/reduce conflicts. In this case, we mark each of the conflicting rules. For example, %glr-parser %expect-rr 1 %% stmt: target_list '=' expr ';' | expr_list ';' ; target_list: target | target ',' target_list ; target: ID %expect-rr 1 ; expr_list: expr | expr ',' expr_list ; expr: ID %expect-rr 1 | ... ; In a statement such as x, y = 3, 4; the parser must reduce x to a target or an expr, but does not know which until it sees the '='. So we notate the two possible reductions to indicate that each conflicts in one rule. This feature needs user feedback, and might evolve in the future. *** ✨ C++: Actual token constructors When variants and token constructors are enabled, in addition to the type-safe named token constructors (make_ID, amke_INT, etc.), we now generate genuine constructors for symbol_type. For instance with these declarations %token ':' <std::string> ID <int> INT; you may use these constructors: symbol_type (int token, const std::string&); symbol_type (int token, const int&); symbol_type (int token); which should be used in a Flex-scanner as follows. %% [a-z]+ return yy::parser::symbol_type (ID, yytext); [0-9]+ return yy::parser::symbol_type (INT, text_to_int (yytext); ":" return yy::parser::symbol_type (’:’); <<EOF>> return yy::parser::symbol_type (0); Correct matching between token types and value types is checked via 'assert'. For instance, 'symbol_type (ID, 42)' would abort (while 'make_ID (42)' would not even compile). *** ✨ C++: Variadic emplace If your application requires C++11 and you don't use symbol constructors, you may now use a variadic emplace for semantic values: %define api.value.type variant %token <std::pair<int, int>> PAIR in your scanner: int yylex (parser::semantic_type *lvalp) { lvalp->emplace <std::pair<int, int>> (1, 2); return parser::token::PAIR; } *** ✨ C++: Syntax error exceptions in GLR The glr.cc skeleton now supports syntax_error exceptions thrown from user actions, or from the scanner. *** 🚨 More POSIX Yacc compatibility warnings More Bison specific directives are now reported with -y or -Wyacc. This change was ready since the release of Bison 3.0 in September 2015. It was delayed because Autoconf used to define YACC as `bison -y`, which resulted in numerous warnings for Bison users that use the GNU Build System. If you still experience that problem, either redefine YACC as `bison -o y.tab.c`, or pass -Wno-yacc to Bison. *** The tables yyrhs and yyphrs are back Because no Bison skeleton uses them, these tables were removed (no longer passed to the skeletons, not even computed) in 2008. However, some users have expressed interest in being able to use them in their own skeletons. ** 🐛 Bug fixes *** Incorrect number of reduce-reduce conflicts On a grammar such as exp: "num" | "num" | "num" bison used to report a single RR conflict, instead of two. This is now fixed. This was the oldest (known) bug in Bison: it was there when Bison was entered in the RCS version control system, in December 1987. Some grammar files might have to adjust their %expect-rr. *** Parser directives that were not careful enough Passing invalid arguments to %nterm, for instance character literals, used to result in unclear error messages. ** 📚 Documentation The examples/ directory (installed in .../share/doc/bison/examples) has been restructured per language for clarity. The examples come with a README and a Makefile. Not only can they be used to toy with Bison, they can also be starting points for your own grammars. There is now a Java example, and a simple example in C based on Flex and Bison (examples/c/lexcalc/). ** 💰 Changes *** Parsers in C++ They now use noexcept and constexpr. Please, report missing annotations. *** Symbol Declarations The syntax of the variation directives to declare symbols was overhauled for more consistency, and also better POSIX Yacc compliance (which, for instance, allows "%type" without actually providing a type). The %nterm directive, supported by Bison since its inception, is now documented and officially supported. The syntax is now as follows: %token TAG? ( ID NUMBER? STRING? )+ ( TAG ( ID NUMBER? STRING? )+ )* %left TAG? ( ID NUMBER? )+ ( TAG ( ID NUMBER? )+ )* %type TAG? ( ID | CHAR | STRING )+ ( TAG ( ID | CHAR | STRING )+ )* %nterm TAG? ID+ ( TAG ID+ )* where TAG denotes a type tag such as ‘<ival>’, ID denotes an identifier such as ‘NUM’, NUMBER a decimal or hexadecimal integer such as ‘300’ or ‘0x12d’, CHAR a character literal such as ‘'+'’, and STRING a string literal such as ‘"number"’. The postfix quantifiers are ‘?’ (zero or one), ‘*’ (zero or more) and ‘+’ (one or more). _______________________________________________ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
