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
 * 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.
 
 ** 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
 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
 ** 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\"",
 
 
   "\"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:
 
 ** 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.
 
 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
 
 
 * 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?
 
 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:
 
 * Coding system independence
 Paul notes:
 


@@ -268,29 +249,6 @@ Show reductions.
 ** Skeleton strategy
 Must we keep %token-table?
 
 ** 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
 * Precedence
 
 ** Partial order