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