Future/bison
1
0
Fork 0
mirror of https://git.savannah.gnu.org/git/bison.git synced 2026-03-09 12:23:04 +00:00
Code Issues Packages Projects Releases Wiki Activity

Document Yacc prologue alternatives and default %destructor's and

Browse Source 
%printer's as experimental.  Don't mention Java yet.  Discussed at
<http://lists.gnu.org/archive/html/bison-patches/2006-12/msg00002.html>.
* NEWS (2.3a+): Say they're experimental.  Remove any mention of Java.
(2.3a): Annotate this entry to say the old forms of these features were
also experimental.
* doc/bison.texinfo (Prologue Alternatives, Freeing Discarded Symbols,
Bison Symbols): Say they're experimental.  Comment out any mention
of Java (we'll want this back eventually).
This commit is contained in:
Joel E. Denny
2006-12-05 23:13:41 +00:00
parent 02975b9aad
commit 8589431355
3 changed files with 105 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files

73
NEWS
View File

@@ -54,6 +54,10 @@ Changes in version 2.3a+ (????-??-??):
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.
@@ -63,68 +67,68 @@ Changes in version 2.3a+ (????-??-??):
1. %code {CODE}
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:
should write verbatim code for the parser implementation. It replaces
the traditional Yacc prologue, `%{CODE%}', for most purposes. Compare
with:
- `%{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.
- `%{CODE%}' appearing after the first `%union {CODE}' in a 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.
2. %requires {CODE}
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:
definitions required by Bison. 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. Compare with:
- `%{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.
- `%{CODE%}' appearing before the first `%union {CODE}' in a 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.
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
Bison to expose externally. That is, 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:
Bison's required definitions. Compare with:
- `%end-header {CODE}', which only Bison 2.3a supported.
4. %code-top {CODE}
Occasionally for C/C++ it is desirable to insert code near the top of
the parser code file. For example:
Occasionally it is desirable to insert code near the top of the parser
code file. For example:
%code-top {
#define _GNU_SOURCE
#include <stdio.h>
}
For Java, `%code-top {CODE}' is currently unused. Compare with:
Compare with:
- `%{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}'.
- `%{CODE%}' appearing before the first `%union {CODE}' in a 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.
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.
The prologue alternatives are experimental. More user feedback will help to
determine whether they should become permanent features.
Also see the new section `Prologue Alternatives' in the Bison manual.
Changes in version 2.3a, 2006-09-13:
@@ -160,6 +164,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.
[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
@@ -230,6 +238,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.
[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.