parser: style changes

[bison.git] / TODO

diff --git a/TODO b/TODO
index 13c1f85877e1e1dd22ac69e3b1f8c629af0da95f..02f3efb34ff9371010fda9bd2c0680ed260ccdc4 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,13 +1,22 @@
 * Short term
-** Variable names.
-What should we name `variant' and `lex_symbol'?
+** m4 names
+b4_shared_declarations is no longer what it is.  Make it
+b4_parser_declaration for instance.
+
+** glr.cc: %defines
+it should not be mandatory.
 
-** Use b4_symbol in all the skeleton
-Move its definition in the more standard places and deploy it in other
-skeletons.  Then remove the older system, including the tables
-generated by output.c
+** $ and others in epilogue
+A stray $ is a warning in the actions, but an error in the epilogue.
+IMHO, it should not even be a warning in the epilogue.
 
-** Update the documentation on gnu.org
+** stack.hh
+Get rid of it.  The original idea is nice, but actually it makes
+the code harder to follow, and uselessly different from the other
+skeletons.
+
+** Variable names.
+What should we name `variant' and `lex_symbol'?
 
 ** Get rid of fake #lines [Bison: ...]
 Possibly as simple as checking whether the column number is nonnegative.
@@ -39,10 +48,6 @@ as lr0.cc, why upper case?
 Enhance bench.pl with %b to run different bisons.
 
 * Various
-** Warnings
-Warnings about type tags that are used in printer and dtors, but not
-for symbols?
-
 ** 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
@@ -88,9 +93,6 @@ so both 256 and 257 are "mysterious".
   "\"end of command\"", "error", "$undefined", "\"=\"", "\"break\"",
 
 
-** YYFAIL
-It is seems to be *really* obsolete now, shall we remove it?
-
 ** yychar == yyempty_
 The code in yyerrlab reads:
 
@@ -125,21 +127,6 @@ we do the same in yacc.c.
 The code bw glr.c and yacc.c is really alike, we can certainly factor
 some parts.
 
-* Header guards
-
-From François: should we keep the directory part in the CPP guard?
-
-
-* Yacc.c: CPP Macros
-
-Do some people use YYPURE, YYLSP_NEEDED like we do in the test suite?
-They should not: it is not documented.  But if they need to, let's
-find something clean (not like YYLSP_NEEDED...).
-
-
-* Documentation
-Before releasing, make sure the documentation ("Understanding your
-parser") refers to the current `output' format.
 
 * Report
 
@@ -237,12 +224,6 @@ this issue.  Does anybody have it?
 Some history of Bison and some bibliography would be most welcome.
 Are there any Texinfo standards for bibliography?
 
-** %printer
-Wow, %printer is not documented.  Clearly mark YYPRINT as obsolete.
-
-* Java, Fortran, etc.
-
-
 * Coding system independence
 Paul notes:
 
@@ -268,29 +249,6 @@ Show reductions.
 ** Skeleton strategy
 Must we keep %token-table?
 
-* BTYacc
-See if we can integrate backtracking in Bison.  Charles-Henri de
-Boysson <de-boy_c@epita.fr> has been working on this, but never gave
-the results.
-
-Vadim Maslow, the maintainer of BTYacc was once contacted.  Adjusting
-the Bison grammar parser will be needed to support some extra BTYacc
-features.  This is less urgent.
-
-** Keeping the conflicted actions
-First, analyze the differences between byacc and btyacc (I'm referring
-to the executables).  Find where the conflicts are preserved.
-
-** Compare with the GLR tables
-See how isomorphic the way BTYacc and the way the GLR adjustments in
-Bison are compatible.  *As much as possible* one should try to use the
-same implementation in the Bison executables.  I insist: it should be
-very feasible to use the very same conflict tables.
-
-** Adjust the skeletons
-Import the skeletons for C and C++.
-
-
 * Precedence
 
 ** Partial order