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