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