[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FYI: update TODO
From: |
Akim Demaille |
Subject: |
FYI: update TODO |
Date: |
Thu, 15 Mar 2012 17:15:32 +0100 |
I installed this in master.
From 67218723a0d9f663bfd4bcce25839f7141d6344e Mon Sep 17 00:00:00 2001
From: Akim Demaille <address@hidden>
Date: Thu, 15 Mar 2012 13:56:07 +0100
Subject: [PATCH 1/6] TODO: update.
---
TODO | 44 ++++++++++++++------------------------------
1 file changed, 14 insertions(+), 30 deletions(-)
diff --git a/TODO b/TODO
index 588bf46..24af226 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.
--
1.7.9.2
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- FYI: update TODO,
Akim Demaille <=