]> git.saurik.com Git - bison.git/blame - TODO
* tests/calc.at (_AT_CHECK_CALC_ERROR): Receive as argument the
[bison.git] / TODO
CommitLineData
416bd7a9
MA
1-*- outline -*-
2
fa770c86
AD
3* Unit rules
4Maybe we could expand unit rules, i.e., transform
5
6 exp: arith | bool;
7 arith: exp '+' exp;
8 bool: exp '&' exp;
9
10into
11
12 exp: exp '+' exp | exp '&' exp;
13
14when there are no actions. This can significantly speed up some
15grammars.
16
51dec47b
AD
17* Stupid error messages
18An example shows it easily:
19
20src/bison/tests % ./testsuite -k calc,location,error-verbose -l
21GNU Bison 1.49a test suite test groups:
22
23 NUM: FILENAME:LINE TEST-GROUP-NAME
24 KEYWORDS
25
26 51: calc.at:440 Calculator --locations --yyerror-verbose
27 52: calc.at:442 Calculator --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose
28 54: calc.at:445 Calculator --debug --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose
29src/bison/tests % ./testsuite 51 -d
30## --------------------------- ##
31## GNU Bison 1.49a test suite. ##
32## --------------------------- ##
33 51: calc.at:440 ok
34## ---------------------------- ##
35## All 1 tests were successful. ##
36## ---------------------------- ##
37src/bison/tests % cd ./testsuite.dir/51
38tests/testsuite.dir/51 % echo "()" | ./calc
391.2-1.3: parse error, unexpected ')', expecting error or "number" or '-' or '('
fa770c86
AD
40
41* read_pipe.c
42This is not portable to DOS for instance. Implement a more portable
43scheme. Sources of inspiration include GNU diff, and Free Recode.
44
52d1aeee
MA
45* NEWS
46Sort from 1.31 NEWS.
47
bcb05e75
MA
48* Prologue
49The %union is declared after the user C declarations. It can be
704a47c4 50a problem if YYSTYPE is declared after the user part. []
bcb05e75 51
704a47c4
AD
52Actually, the real problem seems that the %union ought to be output
53where it was defined. For instance, in gettext/intl/plural.y, we
54have:
55
56 %{
57 ...
58 #include "gettextP.h"
59 ...
60 %}
61
62 %union {
63 unsigned long int num;
64 enum operator op;
65 struct expression *exp;
66 }
67
68 %{
69 ...
70 static int yylex PARAMS ((YYSTYPE *lval, const char **pexp));
71 ...
72 %}
73
74Where the first part defines struct expression, the second uses it to
75define YYSTYPE, and the last uses YYSTYPE. Only this order is valid.
bcb05e75
MA
76
77* --graph
78Show reductions. []
79
704a47c4 80* Broken options ?
c3995d99 81** %no-lines [ok]
04a76783 82** %no-parser []
fbbf9b3b 83** %pure-parser []
04a76783
MA
84** %semantic-parser []
85** %token-table []
86** Options which could use parse_dquoted_param ().
87Maybe transfered in lex.c.
88*** %skeleton [ok]
89*** %output []
90*** %file-prefix []
91*** %name-prefix []
ec93a213 92
fbbf9b3b 93** Skeleton strategy. []
c3a8cbaa
MA
94Must we keep %no-parser?
95 %token-table?
fbbf9b3b 96*** New skeletons. []
416bd7a9 97
c111e171 98* src/print_graph.c
31b53af2 99Find the best graph parameters. []
63c2d5de
MA
100
101* doc/bison.texinfo
1a4648ff 102** Update
c3a8cbaa 103informations about ERROR_VERBOSE. []
1a4648ff 104** Add explainations about
c3a8cbaa
MA
105skeleton muscles. []
106%skeleton. []
eeeb962b 107
704a47c4 108* testsuite
c3a8cbaa
MA
109** tests/pure-parser.at []
110New tests.
0f8d586a
AD
111
112* Debugging parsers
113
114From Greg McGary:
115
116akim demaille <akim.demaille@epita.fr> writes:
117
118> With great pleasure! Nonetheless, things which are debatable
119> (or not, but just `big') should be discuss in `public': something
120> like help- or bug-bison@gnu.org is just fine. Jesse and I are there,
121> but there is also Jim and some other people.
122
123I have no idea whether it qualifies as big or controversial, so I'll
124just summarize for you. I proposed this change years ago and was
125surprised that it was met with utter indifference!
126
127This debug feature is for the programs/grammars one develops with
128bison, not for debugging bison itself. I find that the YYDEBUG
129output comes in a very inconvenient format for my purposes.
130When debugging gcc, for instance, what I want is to see a trace of
131the sequence of reductions and the line#s for the semantic actions
132so I can follow what's happening. Single-step in gdb doesn't cut it
133because to move from one semantic action to the next takes you through
134lots of internal machinery of the parser, which is uninteresting.
135
136The change I made was to the format of the debug output, so that it
137comes out in the format of C error messages, digestible by emacs
138compile mode, like so:
139
140grammar.y:1234: foo: bar(0x123456) baz(0x345678)
141
142where "foo: bar baz" is the reduction rule, whose semantic action
143appears on line 1234 of the bison grammar file grammar.y. The hex
144numbers on the rhs tokens are the parse-stack values associated with
145those tokens. Of course, yytype might be something totally
146incompatible with that representation, but for the most part, yytype
147values are single words (scalars or pointers). In the case of gcc,
148they're most often pointers to tree nodes. Come to think of it, the
149right thing to do is to make the printing of stack values be
150user-definable. It would also be useful to include the filename &
151line# of the file being parsed, but the main filename & line# should
152continue to be that of grammar.y
153
154Anyway, this feature has saved my life on numerous occasions. The way
155I customarily use it is to first run bison with the traces on, isolate
156the sequence of reductions that interests me, put those traces in a
157buffer and force it into compile-mode, then visit each of those lines
158in the grammar and set breakpoints with C-x SPACE. Then, I can run
159again under the control of gdb and stop at each semantic action.
160With the hex addresses of tree nodes, I can inspect the values
161associated with any rhs token.
162
163You like?
cd6a695e
AD
164
165* input synclines
166Some users create their foo.y files, and equip them with #line. Bison
167should recognize these, and preserve them.
0e95c1dd
AD
168
169* BTYacc
170See if we can integrate backtracking in Bison. Contact the BTYacc
171maintainers.
172
173* Automaton report
174Display more clearly the lookaheads for each item.
175
176* RR conflicts
177See if we can use precedence between rules to solve RR conflicts. See
178what POSIX says.
179
180* Precedence
181It is unfortunate that there is a total order for precedence. It
182makes it impossible to have modular precedence information. We should
183move to partial orders.
184
185* Parsing grammars
186Rewrite the reader in Bison.