From 67218723a0d9f663bfd4bcce25839f7141d6344e Mon Sep 17 00:00:00 2001 From: Akim Demaille Date: Thu, 15 Mar 2012 13:56:07 +0100 Subject: [PATCH] TODO: update. --- TODO | 44 ++++++++++++++------------------------------ 1 file changed, 14 insertions(+), 30 deletions(-) diff --git a/TODO b/TODO index 588bf468..24af226c 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,11 +38,11 @@ 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 +** Warnings +Warnings about type tags that are used in printer and dtors, but not +for symbols? + ** 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 @@ -154,7 +134,7 @@ some parts. * 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 @@ -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...). -* Installation - * Documentation Before releasing, make sure the documentation ("Understanding your 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 + +Local Variables: +mode: outline +coding: utf-8 +End: + ----- Copyright (C) 2001-2004, 2006, 2008-2012 Free Software Foundation, Inc. -- 2.45.2