-*- 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
* 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
* 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.
projects / bison.git / blobdiff