X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/d115aad9112fb4e2fe1b268c9db7390732d39539..297e263a0050959e0fd139ad66e71383fc9ac4db:/TODO?ds=sidebyside diff --git a/TODO b/TODO index 588bf468..21ef4b91 100644 --- a/TODO +++ b/TODO @@ -1,31 +1,11 @@ --*- 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 +Move its definition in the more standard places and deploy it in other +skeletons. Then remove the older system, including the tables +generated by output.c ** Update the documentation on gnu.org @@ -58,17 +38,10 @@ as lr0.cc, why upper case? ** bench several 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 -** YYPRINT -glr.c inherits its symbol_print function from c.m4, which supports -YYPRINT. But to use YYPRINT yytoknum is needed, which not defined by -glr.c. - -Anyway, IMHO YYPRINT is obsolete and should be restricted to yacc.c. +** Warnings +Warnings about type tags that are used in printer and dtors, but not +for symbols? ** YYERRCODE Defined to 256, but not used, not documented. Probably the token @@ -152,10 +125,6 @@ we do the same in yacc.c. The code bw glr.c and yacc.c is really alike, we can certainly factor some parts. -* Header guards - -From Franc,ois: should we keep the directory part in the CPP guard? - * Yacc.c: CPP Macros @@ -163,13 +132,6 @@ Do some people use YYPURE, YYLSP_NEEDED like we do in the test suite? They should not: it is not documented. But if they need to, let's find something clean (not like YYLSP_NEEDED...). - -* Installation - -* Documentation -Before releasing, make sure the documentation ("Understanding your -parser") refers to the current `output' format. - * Report ** Figures @@ -266,12 +228,6 @@ 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. - - * Coding system independence Paul notes: @@ -297,29 +253,6 @@ Show reductions. ** Skeleton strategy Must we keep %token-table? -* BTYacc -See if we can integrate backtracking in Bison. Charles-Henri de -Boysson has been working on this, but never gave -the results. - -Vadim Maslow, the maintainer of BTYacc was once contacted. Adjusting -the Bison grammar parser will be needed to support some extra BTYacc -features. This is less urgent. - -** Keeping the conflicted actions -First, analyze the differences between byacc and btyacc (I'm referring -to the executables). Find where the conflicts are preserved. - -** Compare with the GLR tables -See how isomorphic the way BTYacc and the way the GLR adjustments in -Bison are compatible. *As much as possible* one should try to use the -same implementation in the Bison executables. I insist: it should be -very feasible to use the very same conflict tables. - -** Adjust the skeletons -Import the skeletons for C and C++. - - * Precedence ** Partial order @@ -403,6 +336,12 @@ Here's a proposal for how a new implementation might look: 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.