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