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