X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/84eedf86fefd2496f288e72731bd0586e0b216f3..47eced3099712180364f4e01b839242027d9a9d8:/TODO?ds=sidebyside

diff --git a/TODO b/TODO
index 5ae4f707..c3aac317 100644
--- a/TODO
+++ b/TODO
@@ -1,6 +1,28 @@
 -*- 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
@@ -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
 
 
-** 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
@@ -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?
 
+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:
@@ -180,6 +216,13 @@ parser") refers to the current `output' format.
 
 * 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
@@ -292,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?
 
-
+** %printer
+Wow, %printer is not documented.  Clearly mark YYPRINT as obsolete.
 
 * Java, Fortran, etc.
 
@@ -413,8 +457,8 @@ Equip the parser with a means to create the (visual) parse tree.
 
 -----
 
-Copyright (C) 2001, 2002, 2003, 2004, 2006, 2008 Free Software Foundation,
-Inc.
+Copyright (C) 2001, 2002, 2003, 2004, 2006, 2008-2009 Free Software
+Foundation, Inc.
 
 This file is part of Bison, the GNU Compiler Compiler.