]> git.saurik.com Git - bison.git/blob - TODO
(jm_PREREQ_QUOTEARG): AC_MBSTATE_T -> AC_TYPE_MBSTATE_T.
[bison.git] / TODO
1 -*- outline -*-
2
3 * URGENT: Documenting C++ output
4 Write a first documentation for C++ output.
5
6
7 * Documentation
8 Before releasing, make sure the documentation refers to the current
9 `output' format.
10
11
12 * Error messages
13 Some are really funky. For instance
14
15 type clash (`%s' `%s') on default action
16
17 is really weird. Revisit them all.
18
19
20 * read_pipe.c
21 This is not portable to DOS for instance. Implement a more portable
22 scheme. Sources of inspiration include GNU diff, and Free Recode.
23
24
25 * value_components_used
26 Was defined but not used: where was it coming from? It can't be to
27 check if %union is used, since the user is free to $<foo>n on her
28 union, doesn't she?
29
30
31 * Report
32
33 ** GLR
34 How would Paul like to display the conflicted actions? In particular,
35 what when two reductions are possible on a given lookahead, but one is
36 part of $default. Should we make the two reductions explicit, or just
37 keep $default? See the following point.
38
39 ** Disabled Reductions
40 See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
41 what we want to do.
42
43 ** Documentation
44 Extend with error productions. The hard part will probably be finding
45 the right rule so that a single state does not exhibit too many yet
46 undocumented ``features''. Maybe an empty action ought to be
47 presented too. Shall we try to make a single grammar with all these
48 features, or should we have several very small grammars?
49
50 ** --report=conflict-path
51 Provide better assistance for understanding the conflicts by providing
52 a sample text exhibiting the (LALR) ambiguity. See the paper from
53 DeRemer and Penello: they already provide the algorithm.
54
55
56 * Extentions
57
58 ** yyerror, yysymprint interface
59 It should be improved, in particular when using Bison features such as
60 locations, and YYPARSE_PARAMS. For the time being, it is recommended
61 to #define yyerror and yyprint to steal internal variables...
62
63 ** Several %unions
64 I think this is a pleasant (but useless currently) feature, but in the
65 future, I want a means to %include other bits of grammars, and _then_
66 it will be important for the various bits to define their needs in
67 %union.
68
69 When implementing multiple-%union support, bare the following in mind:
70
71 - when --yacc, this must be flagged as an error. Don't make it fatal
72 though.
73
74 - The #line must now appear *inside* the definition of yystype.
75 Something like
76
77 {
78 #line 12 "foo.y"
79 int ival;
80 #line 23 "foo.y"
81 char *sval;
82 }
83
84 * Unit rules
85 Maybe we could expand unit rules, i.e., transform
86
87 exp: arith | bool;
88 arith: exp '+' exp;
89 bool: exp '&' exp;
90
91 into
92
93 exp: exp '+' exp | exp '&' exp;
94
95 when there are no actions. This can significantly speed up some
96 grammars. I can't find the papers. In particular the book `LR
97 parsing: Theory and Practice' is impossible to find, but according to
98 `Parsing Techniques: a Practical Guide', it includes information about
99 this issue. Does anybody have it?
100
101
102
103 * Documentation
104
105 ** History/Bibliography
106 Some history of Bison and some bibliography would be most welcome.
107 Are there any Texinfo standards for bibliography?
108
109
110
111
112 * Coding system independence
113 Paul notes:
114
115 Currently Bison assumes 8-bit bytes (i.e. that UCHAR_MAX is
116 255). It also assumes that the 8-bit character encoding is
117 the same for the invocation of 'bison' as it is for the
118 invocation of 'cc', but this is not necessarily true when
119 people run bison on an ASCII host and then use cc on an EBCDIC
120 host. I don't think these topics are worth our time
121 addressing (unless we find a gung-ho volunteer for EBCDIC or
122 PDP-10 ports :-) but they should probably be documented
123 somewhere.
124
125
126
127 * --graph
128 Show reductions. []
129
130 * Broken options ?
131 ** %no-lines [ok]
132 ** %no-parser []
133 ** %pure-parser []
134 ** %token-table []
135 ** Options which could use parse_dquoted_param ().
136 Maybe transfered in lex.c.
137 *** %skeleton [ok]
138 *** %output []
139 *** %file-prefix []
140 *** %name-prefix []
141
142 ** Skeleton strategy. []
143 Must we keep %no-parser?
144 %token-table?
145 *** New skeletons. []
146
147 * src/print_graph.c
148 Find the best graph parameters. []
149
150 * doc/bison.texinfo
151 ** Update
152 informations about ERROR_VERBOSE. []
153 ** Add explainations about
154 skeleton muscles. []
155 %skeleton. []
156
157 * testsuite
158 ** tests/pure-parser.at []
159 New tests.
160
161 * input synclines
162 Some users create their foo.y files, and equip them with #line. Bison
163 should recognize these, and preserve them.
164
165 * BTYacc
166 See if we can integrate backtracking in Bison. Contact the BTYacc
167 maintainers.
168
169 ** Keeping the conflicted actions
170 First, analyze the differences between byacc and btyacc (I'm referring
171 to the executables). Find where the conflicts are preserved.
172
173 ** Compare with the GLR tables
174 See how isomorphic the way BTYacc and the way the GLR adjustements in
175 Bison are compatible. *As much as possible* one should try to use the
176 same implementation in the Bison executables. I insist: it should be
177 very feasible to use the very same conflict tables.
178
179 ** Adjust the skeletons
180 Import the skeletons for C and C++.
181
182 ** Improve the skeletons
183 Have them support yysymprint, yydestruct and so forth.
184
185
186 * Precedence
187
188 ** Partial order
189 It is unfortunate that there is a total order for precedence. It
190 makes it impossible to have modular precedence information. We should
191 move to partial orders (sounds like series/parallel orders to me).
192
193 This will be possible with a Bison parser for the grammar, as it will
194 make it much easier to extend the grammar.
195
196 ** Correlation b/w precedence and associativity
197 Also, I fail to understand why we have to assign the same
198 associativity to operators with the same precedence. For instance,
199 why can't I decide that the precedence of * and / is the same, but the
200 latter is nonassoc?
201
202 If there is really no profound motivation, we should find a new syntax
203 to allow specifying this.
204
205 ** RR conflicts
206 See if we can use precedence between rules to solve RR conflicts. See
207 what POSIX says.
208
209
210 * $undefined
211 From Hans:
212 - If the Bison generated parser experiences an undefined number in the
213 character range, that character is written out in diagnostic messages, an
214 addition to the $undefined value.
215
216 Suggest: Change the name $undefined to undefined; looks better in outputs.
217
218
219 * Default Action
220 From Hans:
221 - For use with my C++ parser, I transported the "switch (yyn)" statement
222 that Bison writes to the bison.simple skeleton file. This way, I can remove
223 the current default rule $$ = $1 implementation, which causes a double
224 assignment to $$ which may not be OK under C++, replacing it with a
225 "default:" part within the switch statement.
226
227 Note that the default rule $$ = $1, when typed, is perfectly OK under C,
228 but in the C++ implementation I made, this rule is different from
229 $<type_name>$ = $<type_name>1. I therefore think that one should implement
230 a Bison option where every typed default rule is explicitly written out
231 (same typed ruled can of course be grouped together).
232
233 Note: Robert Anisko handles this. He knows how to do it.
234
235
236 * Warnings
237 It would be nice to have warning support. See how Autoconf handles
238 them, it is fairly well described there. It would be very nice to
239 implement this in such a way that other programs could use
240 lib/warnings.[ch].
241
242 Don't work on this without first announcing you do, as I already have
243 thought about it, and know many of the components that can be used to
244 implement it.
245
246
247 * Pre and post actions.
248 From: Florian Krohm <florian@edamail.fishkill.ibm.com>
249 Subject: YYACT_EPILOGUE
250 To: bug-bison@gnu.org
251 X-Sent: 1 week, 4 days, 14 hours, 38 minutes, 11 seconds ago
252
253 The other day I had the need for explicitly building the parse tree. I
254 used %locations for that and defined YYLLOC_DEFAULT to call a function
255 that returns the tree node for the production. Easy. But I also needed
256 to assign the S-attribute to the tree node. That cannot be done in
257 YYLLOC_DEFAULT, because it is invoked before the action is executed.
258 The way I solved this was to define a macro YYACT_EPILOGUE that would
259 be invoked after the action. For reasons of symmetry I also added
260 YYACT_PROLOGUE. Although I had no use for that I can envision how it
261 might come in handy for debugging purposes.
262 All is needed is to add
263
264 #if YYLSP_NEEDED
265 YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen, yyloc, (yylsp - yylen));
266 #else
267 YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen);
268 #endif
269
270 at the proper place to bison.simple. Ditto for YYACT_PROLOGUE.
271
272 I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
273 to bison. If you're interested, I'll work on a patch.
274
275 * Move to Graphviz
276 Well, VCG seems really dead. Move to Graphviz instead. Also, equip
277 the parser with a means to create the (visual) parse tree.
278
279 -----
280
281 Copyright (C) 2001, 2002 Free Software Foundation, Inc.
282
283 This file is part of GNU Bison.
284
285 GNU Bison is free software; you can redistribute it and/or modify
286 it under the terms of the GNU General Public License as published by
287 the Free Software Foundation; either version 2, or (at your option)
288 any later version.
289
290 GNU Bison is distributed in the hope that it will be useful,
291 but WITHOUT ANY WARRANTY; without even the implied warranty of
292 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
293 GNU General Public License for more details.
294
295 You should have received a copy of the GNU General Public License
296 along with Bison; see the file COPYING. If not, write to
297 the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
298 Boston, MA 02111-1307, USA.