Future/bison
1
0
Fork 0
mirror of https://git.savannah.gnu.org/git/bison.git synced 2026-03-20 09:43:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

TODO: update.

Browse Source
This commit is contained in:
Akim Demaille
2012-03-15 13:56:07 +01:00
parent 260cee2ded
commit 67218723a0
1 changed files with 14 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
TODO
View File

@@ -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. ** Variable names.
What should we name `variant' and `lex_symbol'? What should we name `variant' and `lex_symbol'?
** Use b4_symbol in all the skeleton ** Use b4_symbol in all the skeleton
Then remove the older system, including the tables generated by Move its definition in the more standard places and deploy it in other
output.c 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,11 +38,11 @@ as lr0.cc, why upper case?
** bench several bisons. ** bench several bisons.
Enhance bench.pl with %b to run different 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
** Warnings
Warnings about type tags that are used in printer and dtors, but not
for symbols?
** YYPRINT ** YYPRINT
glr.c inherits its symbol_print function from c.m4, which supports glr.c inherits its symbol_print function from c.m4, which supports
YYPRINT. But to use YYPRINT yytoknum is needed, which not defined by YYPRINT. But to use YYPRINT yytoknum is needed, which not defined by
@@ -154,7 +134,7 @@ some parts.
* Header guards * Header guards
From Franc,ois: should we keep the directory part in the CPP guard? From François: should we keep the directory part in the CPP guard?
* Yacc.c: CPP Macros * Yacc.c: CPP Macros
@@ -164,8 +144,6 @@ They should not: it is not documented. But if they need to, let's
find something clean (not like YYLSP_NEEDED...). find something clean (not like YYLSP_NEEDED...).
* Installation
* Documentation * Documentation
Before releasing, make sure the documentation ("Understanding your Before releasing, make sure the documentation ("Understanding your
parser") refers to the current `output' format. parser") refers to the current `output' format.
@@ -403,6 +381,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.