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