Merge remote-tracking branch 'origin/maint'

[bison.git] / TODO

diff --git a/TODO b/TODO
index 588bf468af20800d05299a22ae065165746bdaae..21ef4b9135c8688b82acfac405e7cb5e0f34610b 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,31 +1,11 @@
--*- outline -*-
-

 * Short term
 * Short term

-** Use syntax_error from the scanner?
-This would provide a means to raise syntax error from function called
-from the scanner.  Actually, there is no good solution to report a
-lexical error in general.  Usually they are kept at the scanner level
-only, ignoring the guilty token.  But that might not be the best bet,
-since we don't benefit from the syntactic error recovery.
-
-We still have the possibility to return an invalid token number, which
-does the trick.  But then the error message from the parser is poor
-(something like "unexpected $undefined").  Since the scanner probably
-already reported the error, we should directly enter error-recovery,
-without reporting the error message (i.e., YYERROR's semantics).
-
-Back to lalr1.cc (whose name is now quite unfortunate, since it also
-covers lr and ielr), if we support exceptions from yylex, should we
-propose a lexical_error in addition to syntax_error?  Should they have
-a common root, say parse_error?  Should syntax_error be renamed
-syntactic_error for consistency with lexical_error?
-

 ** Variable names.
 What should we name `variant' and `lex_symbol'?
 
 ** Use b4_symbol in all the skeleton
 ** Variable names.
 What should we name `variant' and `lex_symbol'?
 
 ** Use b4_symbol in all the skeleton

-Then remove the older system, including the tables generated by
-output.c
+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

 
 ** Update the documentation on gnu.org
 
 
 ** Update the documentation on gnu.org
 


@@ -58,17 +38,10 @@ as lr0.cc, why upper case?
 ** bench several bisons.
 Enhance bench.pl with %b to run different bisons.
 
 ** 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.
+** 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
 
 ** YYERRCODE
 Defined to 256, but not used, not documented.  Probably the token


@@ -152,10 +125,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 Franc,ois: should we keep the directory part in the CPP guard?
-

 
 * Yacc.c: CPP Macros
 
 
 * Yacc.c: CPP Macros
 


@@ -163,13 +132,6 @@ 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...).
 
 They should not: it is not documented.  But if they need to, let's
 find something clean (not like YYLSP_NEEDED...).
 

-
-* Installation
-
-* Documentation
-Before releasing, make sure the documentation ("Understanding your
-parser") refers to the current `output' format.
-

 * Report
 
 ** Figures
 * Report
 
 ** Figures


@@ -266,12 +228,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:
 


@@ -297,29 +253,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


@@ -403,6 +336,12 @@ Here's a proposal for how a new implementation might look:
 
   http://lists.gnu.org/archive/html/bison-patches/2009-09/msg00086.html
 
 
   http://lists.gnu.org/archive/html/bison-patches/2009-09/msg00086.html
 

+
+Local Variables:
+mode: outline
+coding: utf-8
+End:
+

 -----
 
 Copyright (C) 2001-2004, 2006, 2008-2012 Free Software Foundation, Inc.
 -----
 
 Copyright (C) 2001-2004, 2006, 2008-2012 Free Software Foundation, Inc.