]> git.saurik.com Git - bison.git/blame - TODO
use -Wdeprecated for obsolete %define variable names
[bison.git] / TODO
CommitLineData
ff1b7a13 1* Short term
836dc334
AD
2** push-parser
3Check it too when checking the different kinds of parsers. And be
4sure to check that the initial-action is performed once per parsing.
5
d27c5e65
AD
6** m4 names
7b4_shared_declarations is no longer what it is. Make it
8b4_parser_declaration for instance.
9
c28e8b68
AD
10** $ and others in epilogue
11A stray $ is a warning in the actions, but an error in the epilogue.
12IMHO, it should not even be a warning in the epilogue.
13
5de5b987
AD
14** stack.hh
15Get rid of it. The original idea is nice, but actually it makes
16the code harder to follow, and uselessly different from the other
17skeletons.
18
ff1b7a13
AD
19** Variable names.
20What should we name `variant' and `lex_symbol'?
21
ff1b7a13
AD
22** Get rid of fake #lines [Bison: ...]
23Possibly as simple as checking whether the column number is nonnegative.
24
25I have seen messages like the following from GCC.
26
27<built-in>:0: fatal error: opening dependency file .deps/libltdl/argz.Tpo: No such file or directory
28
29
30** Discuss about %printer/%destroy in the case of C++.
31It would be very nice to provide the symbol classes with an operator<<
32and a destructor. Unfortunately the syntax we have chosen for
33%destroy and %printer make them hard to reuse. For instance, the user
34is invited to write something like
35
36 %printer { debug_stream() << $$; } <my_type>;
37
38which is hard to reuse elsewhere since it wants to use
39"debug_stream()" to find the stream to use. The same applies to
40%destroy: we told the user she could use the members of the Parser
41class in the printers/destructors, which is not good for an operator<<
42since it is no longer bound to a particular parser, it's just a
43(standalone symbol).
44
45** Rename LR0.cc
46as lr0.cc, why upper case?
47
48** bench several bisons.
49Enhance bench.pl with %b to run different bisons.
50
51* Various
ff1b7a13
AD
52** YYERRCODE
53Defined to 256, but not used, not documented. Probably the token
54number for the error token, which POSIX wants to be 256, but which
55Bison might renumber if the user used number 256. Keep fix and doc?
56Throw away?
57
58Also, why don't we output the token name of the error token in the
59output? It is explicitly skipped:
60
61 /* Skip error token and tokens without identifier. */
62 if (sym != errtoken && id)
63
64Of course there are issues with name spaces, but if we disable we have
65something which seems to be more simpler and more consistent instead
66of the special case YYERRCODE.
67
68 enum yytokentype {
69 error = 256,
70 // ...
71 };
72
73
74We could (should?) also treat the case of the undef_token, which is
75numbered 257 for yylex, and 2 internal. Both appear for instance in
76toknum:
77
78 const unsigned short int
79 parser::yytoken_number_[] =
80 {
81 0, 256, 257, 258, 259, 260, 261, 262, 263, 264,
82
83while here
84
85 enum yytokentype {
86 TOK_EOF = 0,
87 TOK_EQ = 258,
88
89so both 256 and 257 are "mysterious".
90
91 const char*
92 const parser::yytname_[] =
93 {
94 "\"end of command\"", "error", "$undefined", "\"=\"", "\"break\"",
95
96
ff1b7a13
AD
97** yychar == yyempty_
98The code in yyerrlab reads:
99
100 if (yychar <= YYEOF)
101 {
102 /* Return failure if at end of input. */
103 if (yychar == YYEOF)
104 YYABORT;
105 }
106
107There are only two yychar that can be <= YYEOF: YYEMPTY and YYEOF.
108But I can't produce the situation where yychar is YYEMPTY here, is it
109really possible? The test suite does not exercise this case.
110
111This shows that it would be interesting to manage to install skeleton
112coverage analysis to the test suite.
113
114** Table definitions
115It should be very easy to factor the definition of the various tables,
116including the separation bw declaration and definition. See for
117instance b4_table_define in lalr1.cc. This way, we could even factor
118C vs. C++ definitions.
119
120* From lalr1.cc to yacc.c
121** Single stack
122Merging the three stacks in lalr1.cc simplified the code, prompted for
123other improvements and also made it faster (probably because memory
124management is performed once instead of three times). I suggest that
125we do the same in yacc.c.
126
127** yysyntax_error
128The code bw glr.c and yacc.c is really alike, we can certainly factor
129some parts.
416bd7a9 130
3c146b5e 131
2ab9a04f 132* Report
ec3bc396 133
ff1b7a13
AD
134** Figures
135Some statistics about the grammar and the parser would be useful,
136especially when asking the user to send some information about the
137grammars she is working on. We should probably also include some
138information about the variables (I'm not sure for instance we even
139specify what LR variant was used).
140
2ab9a04f
AD
141** GLR
142How would Paul like to display the conflicted actions? In particular,
742e4900 143what when two reductions are possible on a given lookahead token, but one is
2ab9a04f
AD
144part of $default. Should we make the two reductions explicit, or just
145keep $default? See the following point.
d7215705 146
2ab9a04f
AD
147** Disabled Reductions
148See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
149what we want to do.
d7215705 150
2ab9a04f 151** Documentation
bc933ef1
AD
152Extend with error productions. The hard part will probably be finding
153the right rule so that a single state does not exhibit too many yet
154undocumented ``features''. Maybe an empty action ought to be
155presented too. Shall we try to make a single grammar with all these
156features, or should we have several very small grammars?
ec3bc396 157
2ab9a04f
AD
158** --report=conflict-path
159Provide better assistance for understanding the conflicts by providing
160a sample text exhibiting the (LALR) ambiguity. See the paper from
161DeRemer and Penello: they already provide the algorithm.
162
38eb7751
PE
163** Statically check for potential ambiguities in GLR grammars. See
164<http://www.i3s.unice.fr/~schmitz/papers.html#expamb> for an approach.
165
ec3bc396 166
948be909 167* Extensions
2ab9a04f 168
959e5f51
AD
169** $-1
170We should find a means to provide an access to values deep in the
171stack. For instance, instead of
172
ff1b7a13 173 baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }
959e5f51
AD
174
175we should be able to have:
176
177 foo($foo) bar($bar) baz($bar): qux($qux) { $baz = $foo + $bar + $qux; }
178
179Or something like this.
180
f0e48240
AD
181** %if and the like
182It should be possible to have %if/%else/%endif. The implementation is
183not clear: should it be lexical or syntactic. Vadim Maslow thinks it
184must be in the scanner: we must not parse what is in a switched off
185part of %if. Akim Demaille thinks it should be in the parser, so as
186to avoid falling into another CPP mistake.
187
ca752c34
AD
188** XML Output
189There are couple of available extensions of Bison targeting some XML
190output. Some day we should consider including them. One issue is
191that they seem to be quite orthogonal to the parsing technique, and
192seem to depend mostly on the possibility to have some code triggered
193for each reduction. As a matter of fact, such hooks could also be
194used to generate the yydebug traces. Some generic scheme probably
195exists in there.
196
197XML output for GNU Bison and gcc
198 http://www.cs.may.ie/~jpower/Research/bisonXML/
199
200XML output for GNU Bison
201 http://yaxx.sourceforge.net/
f0e48240 202
fa770c86
AD
203* Unit rules
204Maybe we could expand unit rules, i.e., transform
205
ff1b7a13
AD
206 exp: arith | bool;
207 arith: exp '+' exp;
208 bool: exp '&' exp;
fa770c86
AD
209
210into
211
ff1b7a13 212 exp: exp '+' exp | exp '&' exp;
fa770c86
AD
213
214when there are no actions. This can significantly speed up some
d7215705
AD
215grammars. I can't find the papers. In particular the book `LR
216parsing: Theory and Practice' is impossible to find, but according to
217`Parsing Techniques: a Practical Guide', it includes information about
218this issue. Does anybody have it?
fa770c86 219
51dec47b 220
51dec47b 221
2ab9a04f 222* Documentation
51dec47b 223
2ab9a04f
AD
224** History/Bibliography
225Some history of Bison and some bibliography would be most welcome.
226Are there any Texinfo standards for bibliography?
227
2ab9a04f
AD
228* Coding system independence
229Paul notes:
230
ff1b7a13
AD
231 Currently Bison assumes 8-bit bytes (i.e. that UCHAR_MAX is
232 255). It also assumes that the 8-bit character encoding is
233 the same for the invocation of 'bison' as it is for the
234 invocation of 'cc', but this is not necessarily true when
235 people run bison on an ASCII host and then use cc on an EBCDIC
236 host. I don't think these topics are worth our time
237 addressing (unless we find a gung-ho volunteer for EBCDIC or
238 PDP-10 ports :-) but they should probably be documented
239 somewhere.
fa770c86 240
ff1b7a13
AD
241 More importantly, Bison does not currently allow NUL bytes in
242 tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
243 the source code. This should get fixed.
aef1ffd5 244
bcb05e75 245* --graph
45567173 246Show reductions.
bcb05e75 247
704a47c4 248* Broken options ?
45567173
AD
249** %token-table
250** Skeleton strategy
728c4be2 251Must we keep %token-table?
416bd7a9 252
0e95c1dd 253* Precedence
2ab9a04f
AD
254
255** Partial order
0e95c1dd
AD
256It is unfortunate that there is a total order for precedence. It
257makes it impossible to have modular precedence information. We should
2ab9a04f 258move to partial orders (sounds like series/parallel orders to me).
0e95c1dd 259
2ab9a04f
AD
260** RR conflicts
261See if we can use precedence between rules to solve RR conflicts. See
262what POSIX says.
263
264
69991a58
AD
265* $undefined
266From Hans:
267- If the Bison generated parser experiences an undefined number in the
268character range, that character is written out in diagnostic messages, an
269addition to the $undefined value.
270
271Suggest: Change the name $undefined to undefined; looks better in outputs.
272
2ab9a04f 273
69991a58
AD
274* Default Action
275From Hans:
276- For use with my C++ parser, I transported the "switch (yyn)" statement
277that Bison writes to the bison.simple skeleton file. This way, I can remove
278the current default rule $$ = $1 implementation, which causes a double
279assignment to $$ which may not be OK under C++, replacing it with a
280"default:" part within the switch statement.
281
282Note that the default rule $$ = $1, when typed, is perfectly OK under C,
283but in the C++ implementation I made, this rule is different from
284$<type_name>$ = $<type_name>1. I therefore think that one should implement
285a Bison option where every typed default rule is explicitly written out
286(same typed ruled can of course be grouped together).
287
288* Pre and post actions.
289From: Florian Krohm <florian@edamail.fishkill.ibm.com>
290Subject: YYACT_EPILOGUE
291To: bug-bison@gnu.org
292X-Sent: 1 week, 4 days, 14 hours, 38 minutes, 11 seconds ago
293
294The other day I had the need for explicitly building the parse tree. I
295used %locations for that and defined YYLLOC_DEFAULT to call a function
296that returns the tree node for the production. Easy. But I also needed
297to assign the S-attribute to the tree node. That cannot be done in
298YYLLOC_DEFAULT, because it is invoked before the action is executed.
299The way I solved this was to define a macro YYACT_EPILOGUE that would
300be invoked after the action. For reasons of symmetry I also added
301YYACT_PROLOGUE. Although I had no use for that I can envision how it
302might come in handy for debugging purposes.
76551463 303All is needed is to add
69991a58
AD
304
305#if YYLSP_NEEDED
306 YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen, yyloc, (yylsp - yylen));
307#else
308 YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen);
309#endif
310
311at the proper place to bison.simple. Ditto for YYACT_PROLOGUE.
312
313I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
314to bison. If you're interested, I'll work on a patch.
315
35fe0834
PE
316* Better graphics
317Equip the parser with a means to create the (visual) parse tree.
d7215705 318
ff1b7a13
AD
319* Complaint submessage indentation.
320We already have an implementation that works fairly well for named
321reference messages, but it would be nice to use it consistently for all
322submessages from Bison. For example, the "previous definition"
323submessage or the list of correct values for a %define variable might
324look better with indentation.
325
326However, the current implementation makes the assumption that the
327location printed on the first line is not usually much shorter than the
328locations printed on the submessage lines that follow. That assumption
329may not hold true as often for some kinds of submessages especially if
330we ever support multiple grammar files.
331
332Here's a proposal for how a new implementation might look:
333
334 http://lists.gnu.org/archive/html/bison-patches/2009-09/msg00086.html
335
336
337Local Variables:
338mode: outline
339coding: utf-8
340End:
341
f294a2c2
AD
342-----
343
c932d613 344Copyright (C) 2001-2004, 2006, 2008-2012 Free Software Foundation, Inc.
f294a2c2 345
51cbef6f 346This file is part of Bison, the GNU Compiler Compiler.
f294a2c2 347
f16b0819 348This program is free software: you can redistribute it and/or modify
f294a2c2 349it under the terms of the GNU General Public License as published by
f16b0819
PE
350the Free Software Foundation, either version 3 of the License, or
351(at your option) any later version.
f294a2c2 352
f16b0819 353This program is distributed in the hope that it will be useful,
f294a2c2
AD
354but WITHOUT ANY WARRANTY; without even the implied warranty of
355MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
356GNU General Public License for more details.
357
358You should have received a copy of the GNU General Public License
f16b0819 359along with this program. If not, see <http://www.gnu.org/licenses/>.