]> git.saurik.com Git - bison.git/blame - TODO
* doc/bison.texinfo (Debugging): Split into...
[bison.git] / TODO
CommitLineData
416bd7a9
MA
1-*- outline -*-
2
ec3bc396
AD
3* documentation
4Explain $axiom (and maybe change its name: BTYacc names it goal).
5Complete the glossary (item, axiom, ?).
6
7* report documentation
8Extend with error. The hard part will probably be finding the right
9rule so that a single state does not exhibit to many yet undocumented
10``features''. Maybe an empty action ought to be presented too. Shall
11we try to make a single grammar with all these features, or should we
12have several very small grammars?
13
14* documentation
15Some history of Bison and some bibliography would be most welcome.
16Are there any Texinfo standards for bibliography?
17
6cbfbcc5
AD
18* Several %unions
19I think this is a pleasant (but useless currently) feature, but in the
20future, I want a means to %include other bits of grammars, and _then_
21it will be important for the various bits to define their needs in
22%union.
76551463 23
5c0a0514
AD
24When implementing multiple-%union support, bare the following in mind:
25
26- when --yacc, this must be flagged as an error. Don't make it fatal
27 though.
28
29- The #line must now appear *inside* the definition of yystype.
30 Something like
31
32 {
33 #line 12 "foo.y"
34 int ival;
35 #line 23 "foo.y"
36 char *sval;
37 }
38
ec3bc396
AD
39* --report=conflict-path
40Provide better assistance for understanding the conflicts by providing
41a sample text exhibiting the (LALR) ambiguity.
308a2f76 42
ec3bc396
AD
43* report
44Solved conflicts should not be reported in the beginning of the file.
45Rather they should be reported within each state description. Also,
46now that the symbol providing the precedence of a rule is kept, it is
47possible to explain why a conflict was solved this way. E.g., instead
48of
308a2f76 49
ec3bc396 50 Conflict in state 8 between rule 2 and token '+' resolved as reduce.
308a2f76 51
ec3bc396 52we can (in state 8) report something like
308a2f76 53
ec3bc396
AD
54 Conflict between rule 2 and token '+' resolved as reduce
55 because '*' < '+'.
308a2f76 56
ec3bc396 57or something like that.
d4e7d3a1 58
eaff5ee3 59* Coding system independence
4358321a 60Paul notes:
eaff5ee3
AD
61
62 Currently Bison assumes 8-bit bytes (i.e. that UCHAR_MAX is
63 255). It also assumes that the 8-bit character encoding is
64 the same for the invocation of 'bison' as it is for the
65 invocation of 'cc', but this is not necessarily true when
66 people run bison on an ASCII host and then use cc on an EBCDIC
67 host. I don't think these topics are worth our time
68 addressing (unless we find a gung-ho volunteer for EBCDIC or
69 PDP-10 ports :-) but they should probably be documented
70 somewhere.
71
8b3ba7ff
AD
72* Output directory
73Akim:
74
75| I consider this to be a bug in bison:
76|
77| /tmp % mkdir src
78| /tmp % cp ~/src/bison/tests/calc.y src
79| /tmp % mkdir build && cd build
80| /tmp/build % bison ../src/calc.y
81| /tmp/build % cd ..
82| /tmp % ls -l build src
83| build:
84| total 0
85|
86| src:
87| total 32
88| -rw-r--r-- 1 akim lrde 27553 oct 2 16:31 calc.tab.c
89| -rw-r--r-- 1 akim lrde 3335 oct 2 16:31 calc.y
90|
91|
92| Would it be safe to change this behavior to something more reasonable?
93| Do you think some people depend upon this?
94
95Jim:
96
97Is it that behavior documented?
98If so, then it's probably not reasonable to change it.
99I've Cc'd the automake list, because some of automake's
100rules use bison through $(YACC) -- though I'll bet they
101all use it in yacc-compatible mode.
102
103Pavel:
104
105Hello, Jim and others!
106
107> Is it that behavior documented?
108> If so, then it's probably not reasonable to change it.
109> I've Cc'd the automake list, because some of automake's
110> rules use bison through $(YACC) -- though I'll bet they
111> all use it in yacc-compatible mode.
112
113Yes, Automake currently used bison in Automake-compatible mode, but it
114would be fair for Automake to switch to the native mode as long as the
115processed files are distributed and "missing" emulates bison.
116
117In any case, the makefiles should specify the output file explicitly
118instead of relying on weird defaults.
119
120> | src:
121> | total 32
122> | -rw-r--r-- 1 akim lrde 27553 oct 2 16:31 calc.tab.c
123> | -rw-r--r-- 1 akim lrde 3335 oct 2 16:31 calc.y
124
125This is not _that_ ugly as it seems - with Automake you want to put
126sources where they belong - to the source directory.
127
128> | This is not _that_ ugly as it seems - with Automake you want to put
129> | sources where they belong - to the source directory.
130>
131> The difference source/build you are referring to is based on Automake
132> concepts. They have no sense at all for tools such as bison or gcc
133> etc. They have input and output. I do not want them to try to grasp
134> source/build. I want them to behave uniformly: output *here*.
135
136I realize that.
137
138It's unfortunate that the native mode of Bison behaves in a less uniform
139way than the yacc mode. I agree with your point. Bison maintainters may
140want to fix it along with the documentation.
141
142
fa770c86
AD
143* Unit rules
144Maybe we could expand unit rules, i.e., transform
145
146 exp: arith | bool;
147 arith: exp '+' exp;
148 bool: exp '&' exp;
149
150into
151
152 exp: exp '+' exp | exp '&' exp;
153
154when there are no actions. This can significantly speed up some
155grammars.
156
51dec47b
AD
157* Stupid error messages
158An example shows it easily:
159
160src/bison/tests % ./testsuite -k calc,location,error-verbose -l
161GNU Bison 1.49a test suite test groups:
162
163 NUM: FILENAME:LINE TEST-GROUP-NAME
164 KEYWORDS
165
166 51: calc.at:440 Calculator --locations --yyerror-verbose
167 52: calc.at:442 Calculator --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose
168 54: calc.at:445 Calculator --debug --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose
169src/bison/tests % ./testsuite 51 -d
170## --------------------------- ##
171## GNU Bison 1.49a test suite. ##
172## --------------------------- ##
173 51: calc.at:440 ok
174## ---------------------------- ##
175## All 1 tests were successful. ##
176## ---------------------------- ##
177src/bison/tests % cd ./testsuite.dir/51
178tests/testsuite.dir/51 % echo "()" | ./calc
1791.2-1.3: parse error, unexpected ')', expecting error or "number" or '-' or '('
fa770c86 180
01c56de4
AD
181* yyerror, yyprint interface
182It should be improved, in particular when using Bison features such as
183locations, and YYPARSE_PARAMS. For the time being, it is recommended
184to #define yyerror and yyprint to steal internal variables...
185
fa770c86
AD
186* read_pipe.c
187This is not portable to DOS for instance. Implement a more portable
188scheme. Sources of inspiration include GNU diff, and Free Recode.
189
aef1ffd5
AD
190* Memory leaks in the generator
191A round of memory leak clean ups would be most welcome. Dmalloc,
192Checker GCC, Electric Fence, or Valgrind: you chose your tool.
193
194* Memory leaks in the parser
195The same applies to the generated parsers. In particular, this is
196critical for user data: when aborting a parsing, when handling the
197error token etc., we often throw away yylval without giving a chance
198of cleaning it up to the user.
199
bcb05e75
MA
200* --graph
201Show reductions. []
202
704a47c4 203* Broken options ?
c3995d99 204** %no-lines [ok]
04a76783 205** %no-parser []
fbbf9b3b 206** %pure-parser []
04a76783
MA
207** %token-table []
208** Options which could use parse_dquoted_param ().
209Maybe transfered in lex.c.
210*** %skeleton [ok]
211*** %output []
212*** %file-prefix []
213*** %name-prefix []
ec93a213 214
fbbf9b3b 215** Skeleton strategy. []
c3a8cbaa
MA
216Must we keep %no-parser?
217 %token-table?
fbbf9b3b 218*** New skeletons. []
416bd7a9 219
c111e171 220* src/print_graph.c
31b53af2 221Find the best graph parameters. []
63c2d5de
MA
222
223* doc/bison.texinfo
1a4648ff 224** Update
c3a8cbaa 225informations about ERROR_VERBOSE. []
1a4648ff 226** Add explainations about
c3a8cbaa
MA
227skeleton muscles. []
228%skeleton. []
eeeb962b 229
704a47c4 230* testsuite
c3a8cbaa
MA
231** tests/pure-parser.at []
232New tests.
0f8d586a
AD
233
234* Debugging parsers
235
236From Greg McGary:
237
238akim demaille <akim.demaille@epita.fr> writes:
239
240> With great pleasure! Nonetheless, things which are debatable
241> (or not, but just `big') should be discuss in `public': something
242> like help- or bug-bison@gnu.org is just fine. Jesse and I are there,
243> but there is also Jim and some other people.
244
245I have no idea whether it qualifies as big or controversial, so I'll
246just summarize for you. I proposed this change years ago and was
247surprised that it was met with utter indifference!
248
249This debug feature is for the programs/grammars one develops with
250bison, not for debugging bison itself. I find that the YYDEBUG
251output comes in a very inconvenient format for my purposes.
252When debugging gcc, for instance, what I want is to see a trace of
253the sequence of reductions and the line#s for the semantic actions
254so I can follow what's happening. Single-step in gdb doesn't cut it
255because to move from one semantic action to the next takes you through
256lots of internal machinery of the parser, which is uninteresting.
257
258The change I made was to the format of the debug output, so that it
259comes out in the format of C error messages, digestible by emacs
260compile mode, like so:
261
262grammar.y:1234: foo: bar(0x123456) baz(0x345678)
263
264where "foo: bar baz" is the reduction rule, whose semantic action
265appears on line 1234 of the bison grammar file grammar.y. The hex
266numbers on the rhs tokens are the parse-stack values associated with
267those tokens. Of course, yytype might be something totally
268incompatible with that representation, but for the most part, yytype
269values are single words (scalars or pointers). In the case of gcc,
270they're most often pointers to tree nodes. Come to think of it, the
271right thing to do is to make the printing of stack values be
272user-definable. It would also be useful to include the filename &
273line# of the file being parsed, but the main filename & line# should
274continue to be that of grammar.y
275
276Anyway, this feature has saved my life on numerous occasions. The way
277I customarily use it is to first run bison with the traces on, isolate
278the sequence of reductions that interests me, put those traces in a
279buffer and force it into compile-mode, then visit each of those lines
280in the grammar and set breakpoints with C-x SPACE. Then, I can run
281again under the control of gdb and stop at each semantic action.
282With the hex addresses of tree nodes, I can inspect the values
283associated with any rhs token.
284
285You like?
cd6a695e
AD
286
287* input synclines
288Some users create their foo.y files, and equip them with #line. Bison
289should recognize these, and preserve them.
0e95c1dd
AD
290
291* BTYacc
292See if we can integrate backtracking in Bison. Contact the BTYacc
293maintainers.
294
295* Automaton report
296Display more clearly the lookaheads for each item.
297
298* RR conflicts
299See if we can use precedence between rules to solve RR conflicts. See
300what POSIX says.
301
302* Precedence
303It is unfortunate that there is a total order for precedence. It
304makes it impossible to have modular precedence information. We should
305move to partial orders.
306
3c9160d9
AD
307This will be possible with a Bison parser for the grammar, as it will
308make it much easier to extend the grammar.
309
0e95c1dd 310* Parsing grammars
3c9160d9 311Rewrite the reader in Flex/Bison. There will be delicate parts, in
9306c70c
AD
312particular, expect the scanner to be hard to write. Many interesting
313features cannot be implemented without such a new reader.
f294a2c2 314
20c37f21
AD
315* Presentation of the report file
316From: "Baum, Nathan I" <s0009525@chelt.ac.uk>
317Subject: Token Alias Bug
318To: "'bug-bison@gnu.org'" <bug-bison@gnu.org>
319
320I've also noticed something, that whilst not *wrong*, is inconvienient: I
321use the verbose mode to help find the causes of unresolved shift/reduce
322conflicts. However, this mode insists on starting the .output file with a
323list of *resolved* conflicts, something I find quite useless. Might it be
324possible to define a -v mode, and a -vv mode -- Where the -vv mode shows
325everything, but the -v mode only tells you what you need for examining
326conflicts? (Or, perhaps, a "*** This state has N conflicts ***" marker above
327each state with conflicts.)
328
69991a58
AD
329* $undefined
330From Hans:
331- If the Bison generated parser experiences an undefined number in the
332character range, that character is written out in diagnostic messages, an
333addition to the $undefined value.
334
335Suggest: Change the name $undefined to undefined; looks better in outputs.
336
337* Default Action
338From Hans:
339- For use with my C++ parser, I transported the "switch (yyn)" statement
340that Bison writes to the bison.simple skeleton file. This way, I can remove
341the current default rule $$ = $1 implementation, which causes a double
342assignment to $$ which may not be OK under C++, replacing it with a
343"default:" part within the switch statement.
344
345Note that the default rule $$ = $1, when typed, is perfectly OK under C,
346but in the C++ implementation I made, this rule is different from
347$<type_name>$ = $<type_name>1. I therefore think that one should implement
348a Bison option where every typed default rule is explicitly written out
349(same typed ruled can of course be grouped together).
350
3c9160d9
AD
351Note: Robert Anisko handles this. He knows how to do it.
352
353* Documenting C++ output
354Write a first documentation for C++ output.
355
0164db68
AD
356* Warnings
357It would be nice to have warning support. See how Autoconf handles
358them, it is fairly well described there. It would be very nice to
359implement this in such a way that other programs could use
360lib/warnings.[ch].
361
9306c70c
AD
362Don't work on this without first announcing you do, as I already have
363thought about it, and know many of the components that can be used to
364implement it.
365
69991a58
AD
366* Pre and post actions.
367From: Florian Krohm <florian@edamail.fishkill.ibm.com>
368Subject: YYACT_EPILOGUE
369To: bug-bison@gnu.org
370X-Sent: 1 week, 4 days, 14 hours, 38 minutes, 11 seconds ago
371
372The other day I had the need for explicitly building the parse tree. I
373used %locations for that and defined YYLLOC_DEFAULT to call a function
374that returns the tree node for the production. Easy. But I also needed
375to assign the S-attribute to the tree node. That cannot be done in
376YYLLOC_DEFAULT, because it is invoked before the action is executed.
377The way I solved this was to define a macro YYACT_EPILOGUE that would
378be invoked after the action. For reasons of symmetry I also added
379YYACT_PROLOGUE. Although I had no use for that I can envision how it
380might come in handy for debugging purposes.
76551463 381All is needed is to add
69991a58
AD
382
383#if YYLSP_NEEDED
384 YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen, yyloc, (yylsp - yylen));
385#else
386 YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen);
387#endif
388
389at the proper place to bison.simple. Ditto for YYACT_PROLOGUE.
390
391I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
392to bison. If you're interested, I'll work on a patch.
393
f294a2c2
AD
394-----
395
396Copyright (C) 2001, 2002 Free Software Foundation, Inc.
397
398This file is part of GNU Autoconf.
399
400GNU Autoconf is free software; you can redistribute it and/or modify
401it under the terms of the GNU General Public License as published by
402the Free Software Foundation; either version 2, or (at your option)
403any later version.
404
405GNU Autoconf is distributed in the hope that it will be useful,
406but WITHOUT ANY WARRANTY; without even the implied warranty of
407MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
408GNU General Public License for more details.
409
410You should have received a copy of the GNU General Public License
411along with autoconf; see the file COPYING. If not, write to
412the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
413Boston, MA 02111-1307, USA.