Rename data_type and stack_symbol_type.

[bison.git] / NEWS

diff --git a/NEWS b/NEWS
index c3fe6d03773edee3183bba7eaab49a02c4c9f3ba..dcaa386d92e060bf78bee8d2da57d91976ef929c 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -1,99 +1,208 @@
 Bison News
 ----------
 
 Bison News
 ----------
 

-Changes in version 2.3a+ (????-??-??):
+Changes in version ?.? (????-??-??):
+
+*
+
+Changes in version 2.4 (2008-11-02):
+
+* %language is an experimental feature.
+
+  We first introduced this feature in test release 2.3b as a cleaner
+  alternative to %skeleton.  Since then, we have discussed the possibility of
+  modifying its effect on Bison's output file names.  Thus, in this release,
+  we consider %language to be an experimental feature that will likely evolve
+  in future releases.
+
+* Forward compatibility with GNU M4 has been improved.
+
+* Several bugs in the C++ skeleton and the experimental Java skeleton have been
+  fixed.
+
+Changes in version 2.3b (2008-05-27):
+
+* The quotes around NAME that used to be required in the following directive
+  are now deprecated:
+
+    %define NAME "VALUE"
+
+* The directive `%pure-parser' is now deprecated in favor of:
+
+    %define api.pure
+
+  which has the same effect except that Bison is more careful to warn about
+  unreasonable usage in the latter case.
+
+* Push Parsing
+
+  Bison can now generate an LALR(1) parser in C with a push interface.  That
+  is, instead of invoking `yyparse', which pulls tokens from `yylex', you can
+  push one token at a time to the parser using `yypush_parse', which will
+  return to the caller after processing each token.  By default, the push
+  interface is disabled.  Either of the following directives will enable it:
+
+    %define api.push_pull "push" // Just push; does not require yylex.
+    %define api.push_pull "both" // Push and pull; requires yylex.
+
+  See the new section `A Push Parser' in the Bison manual for details.
+
+  The current push parsing interface is experimental and may evolve.  More user
+  feedback will help to stabilize it.

 
 * The -g and --graph options now output graphs in Graphviz DOT format,
 
 * The -g and --graph options now output graphs in Graphviz DOT format,

-  not VCG format.
+  not VCG format.  Like --graph, -g now also takes an optional FILE argument
+  and thus cannot be bundled with other short options.

 
 

-* Bison now recognizes two separate kinds of default %destructor's and
-  %printer's:
+* Java

 
 

-    1. Place `<*>' in a %destructor/%printer symbol list to define a default
-       %destructor/%printer for all grammar symbols for which you have formally
-       declared semantic type tags.
+  Bison can now generate an LALR(1) parser in Java.  The skeleton is
+  `data/lalr1.java'.  Consider using the new %language directive instead of
+  %skeleton to select it.

 
 

-    2. Place `<!>' in a %destructor/%printer symbol list to define a default
-       %destructor/%printer for all grammar symbols without declared semantic
-       type tags.
+  See the new section `Java Parsers' in the Bison manual for details.

 
 

-  Bison no longer supports the `%symbol-default' notation from Bison 2.3a.
-  `<*>' and `<!>' combined achieve the same effect with one exception: Bison no
-  longer applies any %destructor to a mid-rule value if that mid-rule value is
-  not actually ever referenced using either $$ or $n in a semantic action.
+  The current Java interface is experimental and may evolve.  More user
+  feedback will help to stabilize it.

 
 

-  See the section `Freeing Discarded Symbols' in the Bison manual for further
-  details.
+* %language
+
+  This new directive specifies the programming language of the generated
+  parser, which can be C (the default), C++, or Java.  Besides the skeleton
+  that Bison uses, the directive affects the names of the generated files if
+  the grammar file's name ends in ".y".
+
+* XML Automaton Report
+
+  Bison can now generate an XML report of the LALR(1) automaton using the new
+  `--xml' option.  The current XML schema is experimental and may evolve.  More
+  user feedback will help to stabilize it.
+
+* The grammar file may now specify the name of the parser header file using
+  %defines.  For example:
+
+    %defines "parser.h"

 
 

-* The Yacc prologue alternatives from Bison 2.3a have been rewritten as the
-  following directives:
+* When reporting useless rules, useless nonterminals, and unused terminals,
+  Bison now employs the terms "useless in grammar" instead of "useless",
+  "useless in parser" instead of "never reduced", and "unused in grammar"
+  instead of "unused".

 
 

-    1. %code {CODE}
+* Unreachable State Removal

 
 

-       Other than semantic actions, this is probably the most common place you
-       should write verbatim code for the parser implementation.  For C/C++, it
-       replaces the traditional Yacc prologue, `%{CODE%}', for most purposes.
-       For Java, it inserts your CODE into the parser class.  Compare with:
+  Previously, Bison sometimes generated parser tables containing unreachable
+  states.  A state can become unreachable during conflict resolution if Bison
+  disables a shift action leading to it from a predecessor state.  Bison now:

 
 

-         - `%{CODE%}' appearing after the first `%union {CODE}' in a C/C++
-           based grammar file.  While Bison will continue to support `%{CODE%}'
-           for backward compatibility, `%code {CODE}' is cleaner as its
-           functionality does not depend on its position in the grammar file
-           relative to any `%union {CODE}'.  Specifically, `%code {CODE}'
-           always inserts your CODE into the parser code file after the usual
-           contents of the parser header file.
-         - `%after-header {CODE}', which only Bison 2.3a supported.
+    1. Removes unreachable states.

 
 

-    2. %requires {CODE}
+    2. Does not report any conflicts that appeared in unreachable states.
+       WARNING: As a result, you may need to update %expect and %expect-rr
+       directives in existing grammar files.

 
 

-       This is the right place to write dependency code for externally exposed
-       definitions required by Bison.  For C/C++, such exposed definitions are
-       those usually appearing in the parser header file.  Thus, this is the
-       right place to define types referenced in `%union {CODE}' directives,
-       and it is the right place to override Bison's default YYSTYPE and
-       YYLTYPE definitions.  For Java, this is the right place to write import
-       directives.  Compare with:
+    3. For any rule used only in such states, Bison now reports the rule as
+       "useless in parser due to conflicts".

 
 

-         - `%{CODE%}' appearing before the first `%union {CODE}' in a C/C++
-           based grammar file.  Unlike `%{CODE%}', `%requires {CODE}' inserts
-           your CODE both into the parser code file and into the parser header
-           file since Bison's required definitions should depend on it in both
-           places.
-         - `%start-header {CODE}', which only Bison 2.3a supported.
+  This feature can be disabled with the following directive:

 
 

-    3. %provides {CODE}
-    
-       This is the right place to write additional definitions you would like
-       Bison to expose externally.  For C/C++, this directive inserts your CODE
-       both into the parser header file and into the parser code file after
-       Bison's required definitions.  For Java, it inserts your CODE into the
-       parser java file after the parser class.  Compare with:
+    %define lr.keep_unreachable_states

 
 

-         - `%end-header {CODE}', which only Bison 2.3a supported.
+  See the %define entry in the `Bison Declaration Summary' in the Bison manual
+  for further discussion.

 
 

-    4. %code-top {CODE}
+* Lookahead Set Correction in the `.output' Report

 
 

-       Occasionally for C/C++ it is desirable to insert code near the top of
-       the parser code file.  For example:
+  When instructed to generate a `.output' file including lookahead sets
+  (using `--report=lookahead', for example), Bison now prints each reduction's
+  lookahead set only next to the associated state's one item that (1) is
+  associated with the same rule as the reduction and (2) has its dot at the end
+  of its RHS.  Previously, Bison also erroneously printed the lookahead set
+  next to all of the state's other items associated with the same rule.  This
+  bug affected only the `.output' file and not the generated parser source
+  code.

 
 

-         %code-top {
-           #define _GNU_SOURCE
-           #include <stdio.h>
-         }
+* --report-file=FILE is a new option to override the default `.output' file
+  name.

 
 

-       For Java, `%code-top {CODE}' is currently unused.  Compare with:
+* The `=' that used to be required in the following directives is now
+  deprecated:

 
 

-         - `%{CODE%}' appearing before the first `%union {CODE}' in a C/C++
-           based grammar file.  `%code-top {CODE}' is cleaner as its
-           functionality does not depend on its position in the grammar file
-           relative to any `%union {CODE}'.
-         - `%before-header {CODE}', which only Bison 2.3a supported.
+    %file-prefix "parser"
+    %name-prefix "c_"
+    %output "parser.c"

 
 

-  If you have multiple occurrences of any one of the above four directives,
-  Bison will concatenate the contents in the order they appear in the grammar
-  file.
+* An Alternative to `%{...%}' -- `%code QUALIFIER {CODE}'

 
 

-  Also see the new section `Prologue Alternatives' in the Bison manual.
+  Bison 2.3a provided a new set of directives as a more flexible alternative to
+  the traditional Yacc prologue blocks.  Those have now been consolidated into
+  a single %code directive with an optional qualifier field, which identifies
+  the purpose of the code and thus the location(s) where Bison should generate
+  it:
+
+    1. `%code          {CODE}' replaces `%after-header  {CODE}'
+    2. `%code requires {CODE}' replaces `%start-header  {CODE}'
+    3. `%code provides {CODE}' replaces `%end-header    {CODE}'
+    4. `%code top      {CODE}' replaces `%before-header {CODE}'
+
+  See the %code entries in section `Bison Declaration Summary' in the Bison
+  manual for a summary of the new functionality.  See the new section `Prologue
+  Alternatives' for a detailed discussion including the advantages of %code
+  over the traditional Yacc prologues.
+
+  The prologue alternatives are experimental.  More user feedback will help to
+  determine whether they should become permanent features.
+
+* Revised warning: unset or unused mid-rule values
+
+  Since Bison 2.2, Bison has warned about mid-rule values that are set but not
+  used within any of the actions of the parent rule.  For example, Bison warns
+  about unused $2 in:
+
+    exp: '1' { $$ = 1; } '+' exp { $$ = $1 + $4; };
+
+  Now, Bison also warns about mid-rule values that are used but not set.  For
+  example, Bison warns about unset $$ in the mid-rule action in:
+
+    exp: '1' { $1 = 1; } '+' exp { $$ = $2 + $4; };
+
+  However, Bison now disables both of these warnings by default since they
+  sometimes prove to be false alarms in existing grammars employing the Yacc
+  constructs $0 or $-N (where N is some positive integer).
+
+  To enable these warnings, specify the option `--warnings=midrule-values' or
+  `-W', which is a synonym for `--warnings=all'.
+
+* Default %destructor or %printer with `<*>' or `<>'
+
+  Bison now recognizes two separate kinds of default %destructor's and
+  %printer's:
+
+    1. Place `<*>' in a %destructor/%printer symbol list to define a default
+       %destructor/%printer for all grammar symbols for which you have formally
+       declared semantic type tags.
+
+    2. Place `<>' in a %destructor/%printer symbol list to define a default
+       %destructor/%printer for all grammar symbols without declared semantic
+       type tags.
+
+  Bison no longer supports the `%symbol-default' notation from Bison 2.3a.
+  `<*>' and `<>' combined achieve the same effect with one exception: Bison no
+  longer applies any %destructor to a mid-rule value if that mid-rule value is
+  not actually ever referenced using either $$ or $n in a semantic action.
+
+  The default %destructor's and %printer's are experimental.  More user
+  feedback will help to determine whether they should become permanent
+  features.
+
+  See the section `Freeing Discarded Symbols' in the Bison manual for further
+  details.
+
+* %left, %right, and %nonassoc can now declare token numbers.  This is required
+  by POSIX.  However, see the end of section `Operator Precedence' in the Bison
+  manual for a caveat concerning the treatment of literal strings.
+
+* The nonfunctional --no-parser, -n, and %no-parser options have been
+  completely removed from Bison.

 
 Changes in version 2.3a, 2006-09-13:
 
 
 Changes in version 2.3a, 2006-09-13:
 


@@ -128,6 +237,10 @@ Changes in version 2.3a, 2006-09-13:
   also prints its line number to `stdout'.  It performs only the second
   `%destructor' in this case, so it invokes `free' only once.
 
   also prints its line number to `stdout'.  It performs only the second
   `%destructor' in this case, so it invokes `free' only once.
 

+  [Although we failed to mention this here in the 2.3a release, the default
+  %destructor's and %printer's were experimental, and they were rewritten in
+  future versions.]
+

 * Except for LALR(1) parsers in C with POSIX Yacc emulation enabled (with `-y',
   `--yacc', or `%yacc'), Bison no longer generates #define statements for
   associating token numbers with token names.  Removing the #define statements
 * Except for LALR(1) parsers in C with POSIX Yacc emulation enabled (with `-y',
   `--yacc', or `%yacc'), Bison no longer generates #define statements for
   associating token numbers with token names.  Removing the #define statements


@@ -198,6 +311,9 @@ Changes in version 2.3a, 2006-09-13:
   If you have multiple occurrences of any one of the above declarations, Bison
   will concatenate the contents in declaration order.
 
   If you have multiple occurrences of any one of the above declarations, Bison
   will concatenate the contents in declaration order.
 

+  [Although we failed to mention this here in the 2.3a release, the prologue
+  alternatives were experimental, and they were rewritten in future versions.]
+

 * The option `--report=look-ahead' has been changed to `--report=lookahead'.
   The old spelling still works, but is not documented and may be removed
   in a future release.
 * The option `--report=look-ahead' has been changed to `--report=lookahead'.
   The old spelling still works, but is not documented and may be removed
   in a future release.


@@ -912,21 +1028,19 @@ End:
 -----
 
 Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
 -----
 
 Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,

-2004, 2005, 2006 Free Software Foundation, Inc.
+2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.

 
 This file is part of Bison, the GNU Compiler Compiler.
 
 
 This file is part of Bison, the GNU Compiler Compiler.
 

-Bison is free software; you can redistribute it and/or modify
+This program is free software: you can redistribute it and/or modify

 it under the terms of the GNU General Public License as published by
 it under the terms of the GNU General Public License as published by

-the Free Software Foundation; either version 2, or (at your option)
-any later version.
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.

 
 

-Bison is distributed in the hope that it will be useful,
+This program is distributed in the hope that it will be useful,

 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 
 You should have received a copy of the GNU General Public License
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 
 You should have received a copy of the GNU General Public License

-along with autoconf; see the file COPYING.  If not, write to
-the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
-Boston, MA 02110-1301, USA.
+along with this program.  If not, see <http://www.gnu.org/licenses/>.