As a result of the previous patch, it is no longer needed

[bison.git] / TODO

diff --git a/TODO b/TODO
index edb62a8e9eb952a12d62115ea1c2bf796f5e9250..a2057afb2f889d21e211cde7d245983168912840 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,34 +1,147 @@
 -*- outline -*-
 
 -*- outline -*-
 

-* src/reader.c
-** Complete parse_skel_decl () with parse_dquoted_param ().
-** Check and cleanup for CPP-out code.
-
-* src/output.c
-** Output sub-skeleton files.
-*** Useful for %no_parser.
-**** New skeleton.
-** Cleanup dirty CPP-out code.
-** s/definitions/prologue/  s/user_code/epilogue/ [ok].
-** s/macro/muscle/
-** Synchronize `#line' directive with user file.
-
-* src/getargs.c src/lex.c
-** Synchronize percent and command line options.
-
-* src/macrotab.[ch]
-** Removing warnings when compiling. (gcc-warnings) [ok].
-** s/macro/muscle/
+* Unit rules
+Maybe we could expand unit rules, i.e., transform
+
+       exp: arith | bool;
+       arith: exp '+' exp;
+       bool: exp '&' exp;
+
+into
+
+       exp: exp '+' exp | exp '&' exp;
+
+when there are no actions.  This can significantly speed up some
+grammars.
+
+* Useless rules
+We have all the needed material to actually remove them.  Do it.
+Or maybe not, but at least do not include them in the automaton.
+
+* read_pipe.c
+This is not portable to DOS for instance.  Implement a more portable
+scheme.  Sources of inspiration include GNU diff, and Free Recode.
+
+* NEWS
+Sort from 1.31 NEWS.
+
+* Prologue
+The %union is declared after the user C declarations. It can be
+a problem if YYSTYPE is declared after the user part.  []
+
+Actually, the real problem seems that the %union ought to be output
+where it was defined.  For instance, in gettext/intl/plural.y, we
+have:
+
+       %{
+       ...
+       #include "gettextP.h"
+       ...
+       %}
+
+       %union {
+         unsigned long int num;
+         enum operator op;
+         struct expression *exp;
+       }
+
+       %{
+       ...
+       static int yylex PARAMS ((YYSTYPE *lval, const char **pexp));
+       ...
+       %}
+
+Where the first part defines struct expression, the second uses it to
+define YYSTYPE, and the last uses YYSTYPE.  Only this order is valid.
+
+* --graph
+Show reductions.       []
+
+* Broken options ?
+** %no-lines           [ok]
+** %no-parser          []
+** %pure-parser                []
+** %semantic-parser    []
+** %token-table                []
+** Options which could use parse_dquoted_param ().
+Maybe transfered in lex.c.
+*** %skeleton          [ok]
+*** %output            []
+*** %file-prefix       []
+*** %name-prefix       []
+
+** Skeleton strategy.  []
+Must we keep %no-parser?
+            %token-table?
+*** New skeletons.     []

 
 * src/print_graph.c
 
 * src/print_graph.c

-** Find the best graph parameters.
+Find the best graph parameters.        []

 
 * doc/bison.texinfo
 
 * doc/bison.texinfo

-** Echo modifications of prologue and epilogue.
-** Add informations about YYERROR_VERBOSE.
-** Add explainations about skeleton muscles.
-** Add explainations about %skeleton.
+** Update
+informations about ERROR_VERBOSE.      []
+** Add explainations about
+skeleton muscles.      []
+%skeleton.             []
+
+* testsuite
+** tests/pure-parser.at        []
+New tests.
+
+* Debugging parsers
+
+From Greg McGary:
+
+akim demaille <akim.demaille@epita.fr> writes:
+
+> With great pleasure!  Nonetheless, things which are debatable
+> (or not, but just `big') should be discuss in `public': something
+> like help- or bug-bison@gnu.org is just fine.  Jesse and I are there,
+> but there is also Jim and some other people.
+
+I have no idea whether it qualifies as big or controversial, so I'll
+just summarize for you.  I proposed this change years ago and was
+surprised that it was met with utter indifference!
+
+This debug feature is for the programs/grammars one develops with
+bison, not for debugging bison itself.  I find that the YYDEBUG
+output comes in a very inconvenient format for my purposes.
+When debugging gcc, for instance, what I want is to see a trace of
+the sequence of reductions and the line#s for the semantic actions
+so I can follow what's happening.  Single-step in gdb doesn't cut it
+because to move from one semantic action to the next takes you through
+lots of internal machinery of the parser, which is uninteresting.
+
+The change I made was to the format of the debug output, so that it
+comes out in the format of C error messages, digestible by emacs
+compile mode, like so:
+
+grammar.y:1234: foo: bar(0x123456) baz(0x345678)
+
+where "foo: bar baz" is the reduction rule, whose semantic action
+appears on line 1234 of the bison grammar file grammar.y.  The hex
+numbers on the rhs tokens are the parse-stack values associated with
+those tokens.  Of course, yytype might be something totally
+incompatible with that representation, but for the most part, yytype
+values are single words (scalars or pointers).  In the case of gcc,
+they're most often pointers to tree nodes.  Come to think of it, the
+right thing to do is to make the printing of stack values be
+user-definable.  It would also be useful to include the filename &
+line# of the file being parsed, but the main filename & line# should
+continue to be that of grammar.y
+
+Anyway, this feature has saved my life on numerous occasions.  The way
+I customarily use it is to first run bison with the traces on, isolate
+the sequence of reductions that interests me, put those traces in a
+buffer and force it into compile-mode, then visit each of those lines
+in the grammar and set breakpoints with C-x SPACE.  Then, I can run
+again under the control of gdb and stop at each semantic action.
+With the hex addresses of tree nodes, I can inspect the values
+associated with any rhs token.

 
 

-* tests/
-** Repair Bison to success tests. [ok]
+You like?

 
 

+* input synclines
+Some users create their foo.y files, and equip them with #line.  Bison
+should recognize these, and preserve them.