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