TODO

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