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 * Extensions
  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 * Java, Fortran, etc.
 112
 113   Add support for languages other than C and C++.  Here is a proposed
 114   patch for Java:
 115
 116   <http://www.goice.co.jp/member/mo/hack-progs/bison-java.html>
 117
 118
 119
 120 * Coding system independence
 121 Paul notes:
 122
 123         Currently Bison assumes 8-bit bytes (i.e. that UCHAR_MAX is
 124         255).  It also assumes that the 8-bit character encoding is
 125         the same for the invocation of 'bison' as it is for the
 126         invocation of 'cc', but this is not necessarily true when
 127         people run bison on an ASCII host and then use cc on an EBCDIC
 128         host.  I don't think these topics are worth our time
 129         addressing (unless we find a gung-ho volunteer for EBCDIC or
 130         PDP-10 ports :-) but they should probably be documented
 131         somewhere.
 132
 133
 134
 135 * --graph
 136 Show reductions.        []
 137
 138 * Broken options ?
 139 ** %no-lines            [ok]
 140 ** %no-parser           []
 141 ** %pure-parser         []
 142 ** %token-table         []
 143 ** Options which could use parse_dquoted_param ().
 144 Maybe transferred in lex.c.
 145 *** %skeleton           [ok]
 146 *** %output             []
 147 *** %file-prefix        []
 148 *** %name-prefix        []
 149
 150 ** Skeleton strategy.   []
 151 Must we keep %no-parser?
 152              %token-table?
 153 *** New skeletons.      []
 154
 155 * src/print_graph.c
 156 Find the best graph parameters. []
 157
 158 * doc/bison.texinfo
 159 ** Update
 160 informations about ERROR_VERBOSE.       []
 161 ** Add explanations about
 162 skeleton muscles.       []
 163 %skeleton.              []
 164
 165 * testsuite
 166 ** tests/pure-parser.at []
 167 New tests.
 168
 169 * input synclines
 170 Some users create their foo.y files, and equip them with #line.  Bison
 171 should recognize these, and preserve them.
 172
 173 * BTYacc
 174 See if we can integrate backtracking in Bison.  Contact the BTYacc
 175 maintainers.
 176
 177 ** Keeping the conflicted actions
 178 First, analyze the differences between byacc and btyacc (I'm referring
 179 to the executables).  Find where the conflicts are preserved.
 180
 181 ** Compare with the GLR tables
 182 See how isomorphic the way BTYacc and the way the GLR adjustments in
 183 Bison are compatible.  *As much as possible* one should try to use the
 184 same implementation in the Bison executables.  I insist: it should be
 185 very feasible to use the very same conflict tables.
 186
 187 ** Adjust the skeletons
 188 Import the skeletons for C and C++.
 189
 190 ** Improve the skeletons
 191 Have them support yysymprint, yydestruct and so forth.
 192
 193
 194 * Precedence
 195
 196 ** Partial order
 197 It is unfortunate that there is a total order for precedence.  It
 198 makes it impossible to have modular precedence information.  We should
 199 move to partial orders (sounds like series/parallel orders to me).
 200
 201 This will be possible with a Bison parser for the grammar, as it will
 202 make it much easier to extend the grammar.
 203
 204 ** Correlation b/w precedence and associativity
 205 Also, I fail to understand why we have to assign the same
 206 associativity to operators with the same precedence.  For instance,
 207 why can't I decide that the precedence of * and / is the same, but the
 208 latter is nonassoc?
 209
 210 If there is really no profound motivation, we should find a new syntax
 211 to allow specifying this.
 212
 213 ** RR conflicts
 214 See if we can use precedence between rules to solve RR conflicts.  See
 215 what POSIX says.
 216
 217
 218 * $undefined
 219 From Hans:
 220 - If the Bison generated parser experiences an undefined number in the
 221 character range, that character is written out in diagnostic messages, an
 222 addition to the $undefined value.
 223
 224 Suggest: Change the name $undefined to undefined; looks better in outputs.
 225
 226
 227 * Default Action
 228 From Hans:
 229 - For use with my C++ parser, I transported the "switch (yyn)" statement
 230 that Bison writes to the bison.simple skeleton file. This way, I can remove
 231 the current default rule $$ = $1 implementation, which causes a double
 232 assignment to $$ which may not be OK under C++, replacing it with a
 233 "default:" part within the switch statement.
 234
 235 Note that the default rule $$ = $1, when typed, is perfectly OK under C,
 236 but in the C++ implementation I made, this rule is different from
 237 $<type_name>$ = $<type_name>1. I therefore think that one should implement
 238 a Bison option where every typed default rule is explicitly written out
 239 (same typed ruled can of course be grouped together).
 240
 241 Note: Robert Anisko handles this.  He knows how to do it.
 242
 243
 244 * Warnings
 245 It would be nice to have warning support.  See how Autoconf handles
 246 them, it is fairly well described there.  It would be very nice to
 247 implement this in such a way that other programs could use
 248 lib/warnings.[ch].
 249
 250 Don't work on this without first announcing you do, as I already have
 251 thought about it, and know many of the components that can be used to
 252 implement it.
 253
 254
 255 * Pre and post actions.
 256 From: Florian Krohm <florian@edamail.fishkill.ibm.com>
 257 Subject: YYACT_EPILOGUE
 258 To: bug-bison@gnu.org
 259 X-Sent: 1 week, 4 days, 14 hours, 38 minutes, 11 seconds ago
 260
 261 The other day I had the need for explicitly building the parse tree. I
 262 used %locations for that and defined YYLLOC_DEFAULT to call a function
 263 that returns the tree node for the production. Easy. But I also needed
 264 to assign the S-attribute to the tree node. That cannot be done in
 265 YYLLOC_DEFAULT, because it is invoked before the action is executed.
 266 The way I solved this was to define a macro YYACT_EPILOGUE that would
 267 be invoked after the action. For reasons of symmetry I also added
 268 YYACT_PROLOGUE. Although I had no use for that I can envision how it
 269 might come in handy for debugging purposes.
 270 All is needed is to add
 271
 272 #if YYLSP_NEEDED
 273     YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen, yyloc, (yylsp - yylen));
 274 #else
 275     YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen);
 276 #endif
 277
 278 at the proper place to bison.simple. Ditto for YYACT_PROLOGUE.
 279
 280 I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
 281 to bison. If you're interested, I'll work on a patch.
 282
 283 * Move to Graphviz
 284 Well, VCG seems really dead.  Move to Graphviz instead.  Also, equip
 285 the parser with a means to create the (visual) parse tree.
 286
 287 -----
 288
 289 Copyright (C) 2001, 2002 Free Software Foundation, Inc.
 290
 291 This file is part of GNU Bison.
 292
 293 GNU Bison is free software; you can redistribute it and/or modify
 294 it under the terms of the GNU General Public License as published by
 295 the Free Software Foundation; either version 2, or (at your option)
 296 any later version.
 297
 298 GNU Bison is distributed in the hope that it will be useful,
 299 but WITHOUT ANY WARRANTY; without even the implied warranty of
 300 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 301 GNU General Public License for more details.
 302
 303 You should have received a copy of the GNU General Public License
 304 along with Bison; see the file COPYING.  If not, write to
 305 the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 306 Boston, MA 02111-1307, USA.