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