TODO

   1 -*- outline -*-
   2
   3 * Unit rules
   4 Maybe we could expand unit rules, i.e., transform
   5
   6         exp: arith | bool;
   7         arith: exp '+' exp;
   8         bool: exp '&' exp;
   9
  10 into
  11
  12         exp: exp '+' exp | exp '&' exp;
  13
  14 when there are no actions.  This can significantly speed up some
  15 grammars.
  16
  17 * Stupid error messages
  18 An example shows it easily:
  19
  20 src/bison/tests % ./testsuite -k calc,location,error-verbose -l
  21 GNU Bison 1.49a test suite test groups:
  22
  23  NUM: FILENAME:LINE      TEST-GROUP-NAME
  24       KEYWORDS
  25
  26   51: calc.at:440        Calculator --locations --yyerror-verbose
  27   52: calc.at:442        Calculator --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose
  28   54: calc.at:445        Calculator --debug --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose
  29 src/bison/tests % ./testsuite 51 -d
  30 ## --------------------------- ##
  31 ## GNU Bison 1.49a test suite. ##
  32 ## --------------------------- ##
  33  51: calc.at:440       ok
  34 ## ---------------------------- ##
  35 ## All 1 tests were successful. ##
  36 ## ---------------------------- ##
  37 src/bison/tests % cd ./testsuite.dir/51
  38 tests/testsuite.dir/51 % echo "()" | ./calc
  39 1.2-1.3: parse error, unexpected ')', expecting error or "number" or '-' or '('
  40
  41 * read_pipe.c
  42 This is not portable to DOS for instance.  Implement a more portable
  43 scheme.  Sources of inspiration include GNU diff, and Free Recode.
  44
  45 * Memory leaks in the generator
  46 A round of memory leak clean ups would be most welcome.  Dmalloc,
  47 Checker GCC, Electric Fence, or Valgrind: you chose your tool.
  48
  49 * Memory leaks in the parser
  50 The same applies to the generated parsers.  In particular, this is
  51 critical for user data: when aborting a parsing, when handling the
  52 error token etc., we often throw away yylval without giving a chance
  53 of cleaning it up to the user.
  54
  55 * NEWS
  56 Sort from 1.31 NEWS.
  57
  58 * Prologue
  59 The %union is declared after the user C declarations. It can be
  60 a problem if YYSTYPE is declared after the user part.   []
  61
  62 Actually, the real problem seems that the %union ought to be output
  63 where it was defined.  For instance, in gettext/intl/plural.y, we
  64 have:
  65
  66         %{
  67         ...
  68         #include "gettextP.h"
  69         ...
  70         %}
  71
  72         %union {
  73           unsigned long int num;
  74           enum operator op;
  75           struct expression *exp;
  76         }
  77
  78         %{
  79         ...
  80         static int yylex PARAMS ((YYSTYPE *lval, const char **pexp));
  81         ...
  82         %}
  83
  84 Where the first part defines struct expression, the second uses it to
  85 define YYSTYPE, and the last uses YYSTYPE.  Only this order is valid.
  86
  87 * --graph
  88 Show reductions.        []
  89
  90 * Broken options ?
  91 ** %no-lines            [ok]
  92 ** %no-parser           []
  93 ** %pure-parser         []
  94 ** %semantic-parser     []
  95 ** %token-table         []
  96 ** Options which could use parse_dquoted_param ().
  97 Maybe transfered in lex.c.
  98 *** %skeleton           [ok]
  99 *** %output             []
 100 *** %file-prefix        []
 101 *** %name-prefix        []
 102
 103 ** Skeleton strategy.   []
 104 Must we keep %no-parser?
 105              %token-table?
 106 *** New skeletons.      []
 107
 108 * src/print_graph.c
 109 Find the best graph parameters. []
 110
 111 * doc/bison.texinfo
 112 ** Update
 113 informations about ERROR_VERBOSE.       []
 114 ** Add explainations about
 115 skeleton muscles.       []
 116 %skeleton.              []
 117
 118 * testsuite
 119 ** tests/pure-parser.at []
 120 New tests.
 121
 122 * Debugging parsers
 123
 124 From Greg McGary:
 125
 126 akim demaille <akim.demaille@epita.fr> writes:
 127
 128 > With great pleasure!  Nonetheless, things which are debatable
 129 > (or not, but just `big') should be discuss in `public': something
 130 > like help- or bug-bison@gnu.org is just fine.  Jesse and I are there,
 131 > but there is also Jim and some other people.
 132
 133 I have no idea whether it qualifies as big or controversial, so I'll
 134 just summarize for you.  I proposed this change years ago and was
 135 surprised that it was met with utter indifference!
 136
 137 This debug feature is for the programs/grammars one develops with
 138 bison, not for debugging bison itself.  I find that the YYDEBUG
 139 output comes in a very inconvenient format for my purposes.
 140 When debugging gcc, for instance, what I want is to see a trace of
 141 the sequence of reductions and the line#s for the semantic actions
 142 so I can follow what's happening.  Single-step in gdb doesn't cut it
 143 because to move from one semantic action to the next takes you through
 144 lots of internal machinery of the parser, which is uninteresting.
 145
 146 The change I made was to the format of the debug output, so that it
 147 comes out in the format of C error messages, digestible by emacs
 148 compile mode, like so:
 149
 150 grammar.y:1234: foo: bar(0x123456) baz(0x345678)
 151
 152 where "foo: bar baz" is the reduction rule, whose semantic action
 153 appears on line 1234 of the bison grammar file grammar.y.  The hex
 154 numbers on the rhs tokens are the parse-stack values associated with
 155 those tokens.  Of course, yytype might be something totally
 156 incompatible with that representation, but for the most part, yytype
 157 values are single words (scalars or pointers).  In the case of gcc,
 158 they're most often pointers to tree nodes.  Come to think of it, the
 159 right thing to do is to make the printing of stack values be
 160 user-definable.  It would also be useful to include the filename &
 161 line# of the file being parsed, but the main filename & line# should
 162 continue to be that of grammar.y
 163
 164 Anyway, this feature has saved my life on numerous occasions.  The way
 165 I customarily use it is to first run bison with the traces on, isolate
 166 the sequence of reductions that interests me, put those traces in a
 167 buffer and force it into compile-mode, then visit each of those lines
 168 in the grammar and set breakpoints with C-x SPACE.  Then, I can run
 169 again under the control of gdb and stop at each semantic action.
 170 With the hex addresses of tree nodes, I can inspect the values
 171 associated with any rhs token.
 172
 173 You like?
 174
 175 * input synclines
 176 Some users create their foo.y files, and equip them with #line.  Bison
 177 should recognize these, and preserve them.
 178
 179 * BTYacc
 180 See if we can integrate backtracking in Bison.  Contact the BTYacc
 181 maintainers.
 182
 183 * Automaton report
 184 Display more clearly the lookaheads for each item.
 185
 186 * RR conflicts
 187 See if we can use precedence between rules to solve RR conflicts.  See
 188 what POSIX says.
 189
 190 * Precedence
 191 It is unfortunate that there is a total order for precedence.  It
 192 makes it impossible to have modular precedence information.  We should
 193 move to partial orders.
 194
 195 * Parsing grammars
 196 Rewrite the reader in Bison.