YYERRCODE.

[bison.git] / TODO

diff --git a/TODO b/TODO
index 634082ab642e696ff91c8c465af1658edf8849ee..e42c4b5c14a98b1fcaa1c8b745388533612fa040 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,12 +1,42 @@
 -*- outline -*-
 
 * Various
 -*- outline -*-
 
 * 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.
+

 ** YYERRCODE
 Defined to 256, but not used, not documented.  Probably the token
 number for the error token, which POSIX wants to be 256, but which
 Bison might renumber if the user used number 256.  Keep fix and doc?
 Throw away?
 
 ** YYERRCODE
 Defined to 256, but not used, not documented.  Probably the token
 number for the error token, which POSIX wants to be 256, but which
 Bison might renumber if the user used number 256.  Keep fix and doc?
 Throw away?
 

+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:
+
+  const unsigned short int
+  parser::yytoken_number_[] =
+  {
+       0,   256,   257,   258,   259,   260,   261,   262,   263,   264,
+
+while here
+
+   enum yytokentype {
+     TOK_EOF = 0,
+     TOK_EQ = 258,
+
+so both 256 and 257 are "mysterious".
+
+  const char*
+  const parser::yytname_[] =
+  {
+  "\"end of command\"", "error", "$undefined", "\"=\"", "\"break\"",
+
+

 ** YYFAIL
 It is seems to be *really* obsolete now, shall we remove it?
 
 ** YYFAIL
 It is seems to be *really* obsolete now, shall we remove it?
 


@@ -77,6 +107,21 @@ including the separation bw declaration and definition.  See for
 instance b4_table_define in lalr1.cc.  This way, we could even factor
 C vs. C++ definitions.
 
 instance b4_table_define in lalr1.cc.  This way, we could even factor
 C vs. C++ definitions.
 

+* From lalr1.cc to yacc.c
+** Single stack
+Merging the three stacks in lalr1.cc simplified the code, prompted for
+other improvements and also made it faster (probably because memory
+management is performed once instead of three times).  I suggest that
+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.
+

 * Header guards
 
 From Franc,ois: should we keep the directory part in the CPP guard?
 * Header guards
 
 From Franc,ois: should we keep the directory part in the CPP guard?


@@ -95,10 +140,6 @@ find something clean (not like YYLSP_NEEDED...).
 Before releasing, make sure the documentation ("Understanding your
 parser") refers to the current `output' format.
 
 Before releasing, make sure the documentation ("Understanding your
 parser") refers to the current `output' format.
 

-* lalr1.cc
-** I18n
-Catch up with yacc.c.
-

 * Report
 
 **  GLR
 * Report
 
 **  GLR