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 * Huge Grammars
  18 Currently, not only is Bison unable to handle huge grammars because of
  19 internal limitations (see test `big triangle').  Push the limit beyond
  20 253.  Be my guest: fix this!
  21
  22 * read_pipe.c
  23 This is not portable to DOS for instance.  Implement a more portable
  24 scheme.  Sources of inspiration include GNU diff, and Free Recode.
  25
  26 * NEWS
  27 Sort from 1.31 NEWS.
  28
  29 * Prologue
  30 The %union is declared after the user C declarations. It can be
  31 a problem if YYSTYPE is declared after the user part.   []
  32
  33 Actually, the real problem seems that the %union ought to be output
  34 where it was defined.  For instance, in gettext/intl/plural.y, we
  35 have:
  36
  37         %{
  38         ...
  39         #include "gettextP.h"
  40         ...
  41         %}
  42
  43         %union {
  44           unsigned long int num;
  45           enum operator op;
  46           struct expression *exp;
  47         }
  48
  49         %{
  50         ...
  51         static int yylex PARAMS ((YYSTYPE *lval, const char **pexp));
  52         ...
  53         %}
  54
  55 Where the first part defines struct expression, the second uses it to
  56 define YYSTYPE, and the last uses YYSTYPE.  Only this order is valid.
  57
  58 * --graph
  59 Show reductions.        []
  60
  61 * Broken options ?
  62 ** %no-lines            [ok]
  63 ** %no-parser           []
  64 ** %pure-parser         []
  65 ** %semantic-parser     []
  66 ** %token-table         []
  67 ** Options which could use parse_dquoted_param ().
  68 Maybe transfered in lex.c.
  69 *** %skeleton           [ok]
  70 *** %output             []
  71 *** %file-prefix        []
  72 *** %name-prefix        []
  73
  74 ** Skeleton strategy.   []
  75 Must we keep %no-parser?
  76              %token-table?
  77 *** New skeletons.      []
  78
  79 * src/print_graph.c
  80 Find the best graph parameters. []
  81
  82 * doc/bison.texinfo
  83 ** Update
  84 informations about ERROR_VERBOSE.       []
  85 ** Add explainations about
  86 skeleton muscles.       []
  87 %skeleton.              []
  88
  89 * testsuite
  90 ** tests/pure-parser.at []
  91 New tests.
  92
  93 * Debugging parsers
  94
  95 From Greg McGary:
  96
  97 akim demaille <akim.demaille@epita.fr> writes:
  98
  99 > With great pleasure!  Nonetheless, things which are debatable
 100 > (or not, but just `big') should be discuss in `public': something
 101 > like help- or bug-bison@gnu.org is just fine.  Jesse and I are there,
 102 > but there is also Jim and some other people.
 103
 104 I have no idea whether it qualifies as big or controversial, so I'll
 105 just summarize for you.  I proposed this change years ago and was
 106 surprised that it was met with utter indifference!
 107
 108 This debug feature is for the programs/grammars one develops with
 109 bison, not for debugging bison itself.  I find that the YYDEBUG
 110 output comes in a very inconvenient format for my purposes.
 111 When debugging gcc, for instance, what I want is to see a trace of
 112 the sequence of reductions and the line#s for the semantic actions
 113 so I can follow what's happening.  Single-step in gdb doesn't cut it
 114 because to move from one semantic action to the next takes you through
 115 lots of internal machinery of the parser, which is uninteresting.
 116
 117 The change I made was to the format of the debug output, so that it
 118 comes out in the format of C error messages, digestible by emacs
 119 compile mode, like so:
 120
 121 grammar.y:1234: foo: bar(0x123456) baz(0x345678)
 122
 123 where "foo: bar baz" is the reduction rule, whose semantic action
 124 appears on line 1234 of the bison grammar file grammar.y.  The hex
 125 numbers on the rhs tokens are the parse-stack values associated with
 126 those tokens.  Of course, yytype might be something totally
 127 incompatible with that representation, but for the most part, yytype
 128 values are single words (scalars or pointers).  In the case of gcc,
 129 they're most often pointers to tree nodes.  Come to think of it, the
 130 right thing to do is to make the printing of stack values be
 131 user-definable.  It would also be useful to include the filename &
 132 line# of the file being parsed, but the main filename & line# should
 133 continue to be that of grammar.y
 134
 135 Anyway, this feature has saved my life on numerous occasions.  The way
 136 I customarily use it is to first run bison with the traces on, isolate
 137 the sequence of reductions that interests me, put those traces in a
 138 buffer and force it into compile-mode, then visit each of those lines
 139 in the grammar and set breakpoints with C-x SPACE.  Then, I can run
 140 again under the control of gdb and stop at each semantic action.
 141 With the hex addresses of tree nodes, I can inspect the values
 142 associated with any rhs token.
 143
 144 You like?
 145
 146 * input synclines
 147 Some users create their foo.y files, and equip them with #line.  Bison
 148 should recognize these, and preserve them.
 149
 150 * BTYacc
 151 See if we can integrate backtracking in Bison.  Contact the BTYacc
 152 maintainers.
 153
 154 * Automaton report
 155 Display more clearly the lookaheads for each item.
 156
 157 * RR conflicts
 158 See if we can use precedence between rules to solve RR conflicts.  See
 159 what POSIX says.
 160
 161 * Precedence
 162 It is unfortunate that there is a total order for precedence.  It
 163 makes it impossible to have modular precedence information.  We should
 164 move to partial orders.
 165
 166 * Parsing grammars
 167 Rewrite the reader in Bison.