TODO

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