1 |
-*- outline -*- |
-*- outline -*- |
2 |
|
|
3 |
|
* URGENT: Documenting C++ output |
4 |
|
Write a first documentation for C++ output. |
5 |
|
|
6 |
|
* yyerror, yyprint interface |
7 |
|
It should be improved, in particular when using Bison features such as |
8 |
|
locations, and YYPARSE_PARAMS. For the time being, it is recommended |
9 |
|
to #define yyerror and yyprint to steal internal variables... |
10 |
|
|
11 |
* documentation |
* documentation |
12 |
Explain $axiom (and maybe change its name: BTYacc names it goal). |
Explain $axiom (and maybe change its name: BTYacc names it `goal', |
13 |
Complete the glossary (item, axiom, ?). |
byacc `$accept', probably based on AT&T Yacc). Complete the glossary |
14 |
|
(item, axiom, ?). |
15 |
|
|
16 |
* report documentation |
* report documentation |
17 |
Extend with error. The hard part will probably be finding the right |
Extend with error. The hard part will probably be finding the right |
171 |
tests/testsuite.dir/51 % echo "()" | ./calc |
tests/testsuite.dir/51 % echo "()" | ./calc |
172 |
1.2-1.3: parse error, unexpected ')', expecting error or "number" or '-' or '(' |
1.2-1.3: parse error, unexpected ')', expecting error or "number" or '-' or '(' |
173 |
|
|
|
* 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... |
|
|
|
|
174 |
* read_pipe.c |
* read_pipe.c |
175 |
This is not portable to DOS for instance. Implement a more portable |
This is not portable to DOS for instance. Implement a more portable |
176 |
scheme. Sources of inspiration include GNU diff, and Free Recode. |
scheme. Sources of inspiration include GNU diff, and Free Recode. |
300 |
particular, expect the scanner to be hard to write. Many interesting |
particular, expect the scanner to be hard to write. Many interesting |
301 |
features cannot be implemented without such a new reader. |
features cannot be implemented without such a new reader. |
302 |
|
|
|
* 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.) |
|
|
|
|
303 |
* $undefined |
* $undefined |
304 |
From Hans: |
From Hans: |
305 |
- If the Bison generated parser experiences an undefined number in the |
- If the Bison generated parser experiences an undefined number in the |
324 |
|
|
325 |
Note: Robert Anisko handles this. He knows how to do it. |
Note: Robert Anisko handles this. He knows how to do it. |
326 |
|
|
|
* Documenting C++ output |
|
|
Write a first documentation for C++ output. |
|
|
|
|
327 |
* Warnings |
* Warnings |
328 |
It would be nice to have warning support. See how Autoconf handles |
It would be nice to have warning support. See how Autoconf handles |
329 |
them, it is fairly well described there. It would be very nice to |
them, it is fairly well described there. It would be very nice to |