-*- outline -*-
* Short term
-** Document %define assert
+** 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
+
+** Update the documentation on gnu.org
+
+** Get rid of fake #lines [Bison: ...]
+Possibly as simple as checking whether the column number is nonnegative.
+
+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
+
** Discuss about %printer/%destroy in the case of C++.
It would be very nice to provide the symbol classes with an operator<<
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 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
* 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
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.
-----
-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.
projects / bison.git / blobdiff