Upgrade gnulib.

[bison.git] / TODO

diff --git a/TODO b/TODO
index ae89c9274c5b67345450ac7418da8f058d0bbaf8..5ae4f707c48e2a6de681721e3589deadd5ab4b47 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,12 +1,84 @@
 -*- outline -*-
 
 -*- outline -*-
 

+* Short term
+** Use b4_symbol in all the skeleton
+Then remove the older system, including the tables generated by
+output.c
+
+** Update the documentation on gnu.org
+
+** Get rid of fake #lines [Bison: ...]
+Possibly as simple as checking whether the column number is nonnegative.
+
+I have seen messages like the following from GCC.
+
+<built-in>:0: fatal error: opening dependency file .deps/libltdl/argz.Tpo: No such file or directory
+
+
+** Document %define assert
+
+** Discuss about %printer/%destroy in the case of C++.
+It would be very nice to provide the symbol classes with an operator<<
+and a destructor.  Unfortunately the syntax we have chosen for
+%destroy and %printer make them hard to reuse.  For instance, the user
+is invited to write something like
+
+   %printer { debug_stream() << $$; } <my_type>;
+
+which is hard to reuse elsewhere since it wants to use
+"debug_stream()" to find the stream to use.  The same applies to
+%destroy: we told the user she could use the members of the Parser
+class in the printers/destructors, which is not good for an operator<<
+since it is no longer bound to a particular parser, it's just a
+(standalone symbol).
+
+** Rename LR0.cc
+as lr0.cc, why upper case?
+
+** bench several bisons.
+Enhance bench.pl with %b to run different bisons.
+
+** Use b4_symbol everywhere.
+Move its definition in the more standard places and deploy it in other
+skeletons.
+

 * Various
 * Various

+** YYPRINT
+glr.c inherits its symbol_print function from c.m4, which supports
+YYPRINT.  But to use YYPRINT yytoknum is needed, which not defined by
+glr.c.
+
+Anyway, IMHO YYPRINT is obsolete and should be restricted to yacc.c.
+

 ** YYERRCODE
 Defined to 256, but not used, not documented.  Probably the token
 number for the error token, which POSIX wants to be 256, but which
 Bison might renumber if the user used number 256.  Keep fix and doc?
 Throw away?
 
 ** YYERRCODE
 Defined to 256, but not used, not documented.  Probably the token
 number for the error token, which POSIX wants to be 256, but which
 Bison might renumber if the user used number 256.  Keep fix and doc?
 Throw away?
 

+We could (should?) also treat the case of the undef_token, which is
+numbered 257 for yylex, and 2 internal.  Both appear for instance in
+toknum:
+
+  const unsigned short int
+  parser::yytoken_number_[] =
+  {
+       0,   256,   257,   258,   259,   260,   261,   262,   263,   264,
+
+while here
+
+   enum yytokentype {
+     TOK_EOF = 0,
+     TOK_EQ = 258,
+
+so both 256 and 257 are "mysterious".
+
+  const char*
+  const parser::yytname_[] =
+  {
+  "\"end of command\"", "error", "$undefined", "\"=\"", "\"break\"",
+
+

 ** YYFAIL
 It is seems to be *really* obsolete now, shall we remove it?
 
 ** YYFAIL
 It is seems to be *really* obsolete now, shall we remove it?
 


@@ -85,8 +157,8 @@ management is performed once instead of three times).  I suggest that
 we do the same in yacc.c.
 
 ** yysyntax_error
 we do the same in yacc.c.
 
 ** yysyntax_error

-In lalr1.cc we invoke it with the translated lookahead (yytoken), and
-yacc.c uses yychar.  I don't see why.
+The code bw glr.c and yacc.c is really alike, we can certainly factor
+some parts.

 
 * Header guards
 
 
 * Header guards
 


@@ -106,10 +178,6 @@ find something clean (not like YYLSP_NEEDED...).
 Before releasing, make sure the documentation ("Understanding your
 parser") refers to the current `output' format.
 
 Before releasing, make sure the documentation ("Understanding your
 parser") refers to the current `output' format.
 

-* lalr1.cc
-** I18n
-Catch up with yacc.c.
-

 * Report
 
 **  GLR
 * Report
 
 **  GLR