Pacify ./configure --enable-gcc-warnings.
[bison.git] / TODO
0 / 309 (  0%)
CommitLineData
1-*- outline -*-
2
3* Header guards
4
5From Franc,ois: should we keep the directory part in the CPP guard?
6
7
8* Yacc.c: CPP Macros
9
10Do some people use YYPURE, YYLSP_NEEDED like we do in the test suite?
11They should not: it is not documented. But if they need to, let's
12find something clean (not like YYLSP_NEEDED...).
13
14
15* Installation
16
17* Documentation
18Before releasing, make sure the documentation ("Understanding your
19parser") refers to the current `output' format.
20
21* lalr1.cc
22** vector
23Move to using vector, drop stack.hh.
24
25** I18n
26Catch up with yacc.c.
27
28* Report
29
30** GLR
31How would Paul like to display the conflicted actions? In particular,
32what when two reductions are possible on a given lookahead token, but one is
33part of $default. Should we make the two reductions explicit, or just
34keep $default? See the following point.
35
36** Disabled Reductions
37See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
38what we want to do.
39
40** Documentation
41Extend with error productions. The hard part will probably be finding
42the right rule so that a single state does not exhibit too many yet
43undocumented ``features''. Maybe an empty action ought to be
44presented too. Shall we try to make a single grammar with all these
45features, or should we have several very small grammars?
46
47** --report=conflict-path
48Provide better assistance for understanding the conflicts by providing
49a sample text exhibiting the (LALR) ambiguity. See the paper from
50DeRemer and Penello: they already provide the algorithm.
51
52** Statically check for potential ambiguities in GLR grammars. See
53<http://www.i3s.unice.fr/~schmitz/papers.html#expamb> for an approach.
54
55
56* Extensions
57
58** Labeling the symbols
59Have a look at the Lemon parser generator: instead of $1, $2 etc. they
60can name the values. This is much more pleasant. For instance:
61
62 exp (res): exp (a) '+' exp (b) { $res = $a + $b; };
63
64I love this. I have been bitten too often by the removal of the
65symbol, and forgetting to shift all the $n to $n-1. If you are
66unlucky, it compiles...
67
68But instead of using $a etc., we can use regular variables. And
69instead of using (), I propose to use `:' (again). Paul suggests
70supporting `->' in addition to `:' to separate LHS and RHS. In other
71words:
72
73 r:exp -> a:exp '+' b:exp { r = a + b; };
74
75That requires an significant improvement of the grammar parser. Using
76GLR would be nice. It also requires that Bison know the type of the
77symbols (which will be useful for %include anyway). So we have some
78time before...
79
80Note that there remains the problem of locations: `@r'?
81
82
83** $-1
84We should find a means to provide an access to values deep in the
85stack. For instance, instead of
86
87 baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }
88
89we should be able to have:
90
91 foo($foo) bar($bar) baz($bar): qux($qux) { $baz = $foo + $bar + $qux; }
92
93Or something like this.
94
95** %if and the like
96It should be possible to have %if/%else/%endif. The implementation is
97not clear: should it be lexical or syntactic. Vadim Maslow thinks it
98must be in the scanner: we must not parse what is in a switched off
99part of %if. Akim Demaille thinks it should be in the parser, so as
100to avoid falling into another CPP mistake.
101
102** -D, --define-muscle NAME=VALUE
103To define muscles via cli. Or maybe support directly NAME=VALUE?
104
105** XML Output
106There are couple of available extensions of Bison targeting some XML
107output. Some day we should consider including them. One issue is
108that they seem to be quite orthogonal to the parsing technique, and
109seem to depend mostly on the possibility to have some code triggered
110for each reduction. As a matter of fact, such hooks could also be
111used to generate the yydebug traces. Some generic scheme probably
112exists in there.
113
114XML output for GNU Bison and gcc
115 http://www.cs.may.ie/~jpower/Research/bisonXML/
116
117XML output for GNU Bison
118 http://yaxx.sourceforge.net/
119
120* Unit rules
121Maybe we could expand unit rules, i.e., transform
122
123 exp: arith | bool;
124 arith: exp '+' exp;
125 bool: exp '&' exp;
126
127into
128
129 exp: exp '+' exp | exp '&' exp;
130
131when there are no actions. This can significantly speed up some
132grammars. I can't find the papers. In particular the book `LR
133parsing: Theory and Practice' is impossible to find, but according to
134`Parsing Techniques: a Practical Guide', it includes information about
135this issue. Does anybody have it?
136
137
138
139* Documentation
140
141** History/Bibliography
142Some history of Bison and some bibliography would be most welcome.
143Are there any Texinfo standards for bibliography?
144
145
146
147* Java, Fortran, etc.
148
149
150* Coding system independence
151Paul notes:
152
153 Currently Bison assumes 8-bit bytes (i.e. that UCHAR_MAX is
154 255). It also assumes that the 8-bit character encoding is
155 the same for the invocation of 'bison' as it is for the
156 invocation of 'cc', but this is not necessarily true when
157 people run bison on an ASCII host and then use cc on an EBCDIC
158 host. I don't think these topics are worth our time
159 addressing (unless we find a gung-ho volunteer for EBCDIC or
160 PDP-10 ports :-) but they should probably be documented
161 somewhere.
162
163 More importantly, Bison does not currently allow NUL bytes in
164 tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
165 the source code. This should get fixed.
166
167* --graph
168Show reductions.
169
170* Broken options ?
171** %token-table
172** Skeleton strategy
173Must we keep %token-table?
174
175* src/print_graph.c
176Find the best graph parameters.
177
178* BTYacc
179See if we can integrate backtracking in Bison. Charles-Henri de
180Boysson <de-boy_c@epita.fr> is working on this, and already has some
181results. Vadim Maslow, the maintainer of BTYacc was contacted, and we
182stay in touch with him. Adjusting the Bison grammar parser will be
183needed to support some extra BTYacc features. This is less urgent.
184
185** Keeping the conflicted actions
186First, analyze the differences between byacc and btyacc (I'm referring
187to the executables). Find where the conflicts are preserved.
188
189** Compare with the GLR tables
190See how isomorphic the way BTYacc and the way the GLR adjustments in
191Bison are compatible. *As much as possible* one should try to use the
192same implementation in the Bison executables. I insist: it should be
193very feasible to use the very same conflict tables.
194
195** Adjust the skeletons
196Import the skeletons for C and C++.
197
198** Improve the skeletons
199Have them support yysymprint, yydestruct and so forth.
200
201
202* Precedence
203
204** Partial order
205It is unfortunate that there is a total order for precedence. It
206makes it impossible to have modular precedence information. We should
207move to partial orders (sounds like series/parallel orders to me).
208
209** Correlation b/w precedence and associativity
210Also, I fail to understand why we have to assign the same
211associativity to operators with the same precedence. For instance,
212why can't I decide that the precedence of * and / is the same, but the
213latter is nonassoc?
214
215If there is really no profound motivation, we should find a new syntax
216to allow specifying this.
217
218** RR conflicts
219See if we can use precedence between rules to solve RR conflicts. See
220what POSIX says.
221
222
223* $undefined
224From Hans:
225- If the Bison generated parser experiences an undefined number in the
226character range, that character is written out in diagnostic messages, an
227addition to the $undefined value.
228
229Suggest: Change the name $undefined to undefined; looks better in outputs.
230
231
232* Default Action
233From Hans:
234- For use with my C++ parser, I transported the "switch (yyn)" statement
235that Bison writes to the bison.simple skeleton file. This way, I can remove
236the current default rule $$ = $1 implementation, which causes a double
237assignment to $$ which may not be OK under C++, replacing it with a
238"default:" part within the switch statement.
239
240Note that the default rule $$ = $1, when typed, is perfectly OK under C,
241but in the C++ implementation I made, this rule is different from
242$<type_name>$ = $<type_name>1. I therefore think that one should implement
243a Bison option where every typed default rule is explicitly written out
244(same typed ruled can of course be grouped together).
245
246Note: Robert Anisko handles this. He knows how to do it.
247
248
249* Warnings
250It would be nice to have warning support. See how Autoconf handles
251them, it is fairly well described there. It would be very nice to
252implement this in such a way that other programs could use
253lib/warnings.[ch].
254
255Don't work on this without first announcing you do, as I already have
256thought about it, and know many of the components that can be used to
257implement it.
258
259
260* Pre and post actions.
261From: Florian Krohm <florian@edamail.fishkill.ibm.com>
262Subject: YYACT_EPILOGUE
263To: bug-bison@gnu.org
264X-Sent: 1 week, 4 days, 14 hours, 38 minutes, 11 seconds ago
265
266The other day I had the need for explicitly building the parse tree. I
267used %locations for that and defined YYLLOC_DEFAULT to call a function
268that returns the tree node for the production. Easy. But I also needed
269to assign the S-attribute to the tree node. That cannot be done in
270YYLLOC_DEFAULT, because it is invoked before the action is executed.
271The way I solved this was to define a macro YYACT_EPILOGUE that would
272be invoked after the action. For reasons of symmetry I also added
273YYACT_PROLOGUE. Although I had no use for that I can envision how it
274might come in handy for debugging purposes.
275All is needed is to add
276
277#if YYLSP_NEEDED
278 YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen, yyloc, (yylsp - yylen));
279#else
280 YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen);
281#endif
282
283at the proper place to bison.simple. Ditto for YYACT_PROLOGUE.
284
285I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
286to bison. If you're interested, I'll work on a patch.
287
288* Better graphics
289Equip the parser with a means to create the (visual) parse tree.
290
291-----
292
293Copyright (C) 2001, 2002, 2003, 2004, 2006 Free Software Foundation,
294Inc.
295
296This file is part of Bison, the GNU Compiler Compiler.
297
298This program is free software: you can redistribute it and/or modify
299it under the terms of the GNU General Public License as published by
300the Free Software Foundation, either version 3 of the License, or
301(at your option) any later version.
302
303This program is distributed in the hope that it will be useful,
304but WITHOUT ANY WARRANTY; without even the implied warranty of
305MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
306GNU General Public License for more details.
307
308You should have received a copy of the GNU General Public License
309along with this program. If not, see <http://www.gnu.org/licenses/>.