doc: clean up quotation style in NEWS.

[bison.git] / TODO

diff --git a/TODO b/TODO
index a9ec30838b565d201ad35ff8021a92f8e9c5a5ed..f3bcf19d76b980e88c4d426c74f8fe5876f500e2 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,6 +1,28 @@
 -*- outline -*-
 
 * Short term
 -*- outline -*-
 
 * 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
 Then remove the older system, including the tables generated by
 output.c
 ** Use b4_symbol in all the skeleton
 Then remove the older system, including the tables generated by
 output.c


@@ -15,8 +37,6 @@ 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
 
 
 <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
 ** 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


@@ -56,6 +76,22 @@ 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?
 
 Bison might renumber if the user used number 256.  Keep fix and doc?
 Throw away?
 

+Also, why don't we output the token name of the error token in the
+output?  It is explicitly skipped:
+
+      /* Skip error token and tokens without identifier.  */
+      if (sym != errtoken && id)
+
+Of course there are issues with name spaces, but if we disable we have
+something which seems to be more simpler and more consistent instead
+of the special case YYERRCODE.
+
+   enum yytokentype {
+     error = 256,
+     // ...
+   };
+
+

 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:
 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:


@@ -157,12 +193,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.
-
-** yysyntax_error
-The use of switch to select yyfmt in lalr1.cc seems simpler than
-what's done in yacc.c.
+The code bw glr.c and yacc.c is really alike, we can certainly factor
+some parts.

 
 * Header guards
 
 
 * Header guards
 


@@ -184,6 +216,13 @@ parser") refers to the current `output' format.
 
 * Report
 
 
 * Report
 

+** Figures
+Some statistics about the grammar and the parser would be useful,
+especially when asking the user to send some information about the
+grammars she is working on.  We should probably also include some
+information about the variables (I'm not sure for instance we even
+specify what LR variant was used).
+

 **  GLR
 How would Paul like to display the conflicted actions?  In particular,
 what when two reductions are possible on a given lookahead token, but one is
 **  GLR
 How would Paul like to display the conflicted actions?  In particular,
 what when two reductions are possible on a given lookahead token, but one is


@@ -296,7 +335,8 @@ 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.
 
 
 * Java, Fortran, etc.
 


@@ -415,10 +455,26 @@ to bison. If you're interested, I'll work on a patch.
 * Better graphics
 Equip the parser with a means to create the (visual) parse tree.
 
 * Better graphics
 Equip the parser with a means to create the (visual) parse tree.
 

+* Complaint submessage indentation.
+We already have an implementation that works fairly well for named
+reference messages, but it would be nice to use it consistently for all
+submessages from Bison.  For example, the "previous definition"
+submessage or the list of correct values for a %define variable might
+look better with indentation.
+
+However, the current implementation makes the assumption that the
+location printed on the first line is not usually much shorter than the
+locations printed on the submessage lines that follow.  That assumption
+may not hold true as often for some kinds of submessages especially if
+we ever support multiple grammar files.
+
+Here's a proposal for how a new implementation might look:
+
+  http://lists.gnu.org/archive/html/bison-patches/2009-09/msg00086.html
+

 -----
 
 -----
 

-Copyright (C) 2001, 2002, 2003, 2004, 2006, 2008 Free Software Foundation,
-Inc.
+Copyright (C) 2001-2004, 2006, 2008-2011 Free Software Foundation, Inc.

 
 This file is part of Bison, the GNU Compiler Compiler.
 
 
 This file is part of Bison, the GNU Compiler Compiler.