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