TODO

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