TODO

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