-*- outline -*-
+* URGENT: Documenting C++ output
+Write a first documentation for C++ output.
+
+* value_components_used
+Was defined but not used: where was it coming from? It can't be to
+check if %union is used, since the user is free to $<foo>n on her
+union, doesn't she?
+
+* yyerror, yyprint interface
+It should be improved, in particular when using Bison features such as
+locations, and YYPARSE_PARAMS. For the time being, it is recommended
+to #define yyerror and yyprint to steal internal variables...
+
+* documentation
+Explain $axiom (and maybe change its name: BTYacc names it `goal',
+byacc `$accept', probably based on AT&T Yacc). Complete the glossary
+(item, axiom, ?).
+
+* report documentation
+Extend with error. The hard part will probably be finding the right
+rule so that a single state does not exhibit to many yet undocumented
+``features''. Maybe an empty action ought to be presented too. Shall
+we try to make a single grammar with all these features, or should we
+have several very small grammars?
+
+* documentation
+Some history of Bison and some bibliography would be most welcome.
+Are there any Texinfo standards for bibliography?
+
* Several %unions
I think this is a pleasant (but useless currently) feature, but in the
future, I want a means to %include other bits of grammars, and _then_
char *sval;
}
-* Experimental report features
-Decide whether they should be enabled, or optional. For instance, on:
-
- input:
- exp
- | input exp
- ;
-
- exp:
- token1 "1"
- | token2 "2"
- | token3 "3"
- ;
-
- token1: token;
- token2: token;
- token3: token;
-
-the traditional Bison reports:
-
- state 0
-
- $axiom -> . input $ (rule 0)
-
- token shift, and go to state 1
-
- input go to state 2
- exp go to state 3
- token1 go to state 4
- token2 go to state 5
- token3 go to state 6
-
- state 1
-
- token1 -> token . (rule 6)
- token2 -> token . (rule 7)
- token3 -> token . (rule 8)
-
- "2" reduce using rule 7 (token2)
- "3" reduce using rule 8 (token3)
- $default reduce using rule 6 (token1)
-
-while with --trace, i.e., when enabling both the display of non-core
-item sets and the display of lookaheads, Bison now displays:
-
- state 0
-
- $axiom -> . input $ (rule 0)
- input -> . exp (rule 1)
- input -> . input exp (rule 2)
- exp -> . token1 "1" (rule 3)
- exp -> . token2 "2" (rule 4)
- exp -> . token3 "3" (rule 5)
- token1 -> . token (rule 6)
- token2 -> . token (rule 7)
- token3 -> . token (rule 8)
-
- token shift, and go to state 1
-
- input go to state 2
- exp go to state 3
- token1 go to state 4
- token2 go to state 5
- token3 go to state 6
-
- state 1
-
- token1 -> token . ["1"] (rule 6)
- token2 -> token . ["2"] (rule 7)
- token3 -> token . ["3"] (rule 8)
-
- "2" reduce using rule 7 (token2)
- "3" reduce using rule 8 (token3)
- $default reduce using rule 6 (token1)
-
-so decide whether this should be an option, or always enabled. I'm in
-favor of making it the default, but maybe we should tune the output to
-distinguish core item sets from non core:
-
- state 0
- Core:
- $axiom -> . input $ (rule 0)
-
- Derived:
- input -> . exp (rule 1)
- input -> . input exp (rule 2)
- exp -> . token1 "1" (rule 3)
- exp -> . token2 "2" (rule 4)
- exp -> . token3 "3" (rule 5)
- token1 -> . token (rule 6)
- token2 -> . token (rule 7)
- token3 -> . token (rule 8)
-
- token shift, and go to state 1
-
- input go to state 2
- exp go to state 3
- token1 go to state 4
- token2 go to state 5
- token3 go to state 6
-
-
-> So, it seems clear that it has to be an additional option :)
-
-Paul:
-
- There will be further such options in the future, so I'd make
- them all operands of the --report option. E.g., you could do
- something like this:
-
- --report=state --report=lookahead --report=itemset
- --report=conflict-path
-
- where "--verbose" is equivalent to "--report=state", and where
- "--report=conflict-path" reports each path to a conflict
- state.
-
- (As a minor point, I prefer avoiding plurals in option names.
- It's partly for brevity, and partly to avoid wearing out the
- 's' keys in our keyboards. :-)
-
-To implement this, see in the Fileutils the latest versions of
-argmatch and so forth.
-
+* --report=conflict-path
+Provide better assistance for understanding the conflicts by providing
+a sample text exhibiting the (LALR) ambiguity.
* Coding system independence
Paul notes:
tests/testsuite.dir/51 % echo "()" | ./calc
1.2-1.3: parse error, unexpected ')', expecting error or "number" or '-' or '('
-* yyerror, yyprint interface
-It should be improved, in particular when using Bison features such as
-locations, and YYPARSE_PARAMS. For the time being, it is recommended
-to #define yyerror and yyprint to steal internal variables...
-
* read_pipe.c
This is not portable to DOS for instance. Implement a more portable
scheme. Sources of inspiration include GNU diff, and Free Recode.
particular, expect the scanner to be hard to write. Many interesting
features cannot be implemented without such a new reader.
-* Presentation of the report file
-From: "Baum, Nathan I" <s0009525@chelt.ac.uk>
-Subject: Token Alias Bug
-To: "'bug-bison@gnu.org'" <bug-bison@gnu.org>
-
-I've also noticed something, that whilst not *wrong*, is inconvienient: I
-use the verbose mode to help find the causes of unresolved shift/reduce
-conflicts. However, this mode insists on starting the .output file with a
-list of *resolved* conflicts, something I find quite useless. Might it be
-possible to define a -v mode, and a -vv mode -- Where the -vv mode shows
-everything, but the -v mode only tells you what you need for examining
-conflicts? (Or, perhaps, a "*** This state has N conflicts ***" marker above
-each state with conflicts.)
-
* $undefined
From Hans:
- If the Bison generated parser experiences an undefined number in the
Note: Robert Anisko handles this. He knows how to do it.
-* Documenting C++ output
-Write a first documentation for C++ output.
-
* Warnings
It would be nice to have warning support. See how Autoconf handles
them, it is fairly well described there. It would be very nice to
projects / bison.git / blobdiff