YYERRCODE.

[bison.git] / TODO

diff --git a/TODO b/TODO
index 7b473094cf7d7450ea66b48e618f7ead857d6465..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?
 


@@ -54,6 +84,43 @@ what it should look like.  For instance what follows crashes.
     return yyparse ();
   }
 
     return yyparse ();
   }
 

+** yychar == yyempty_
+The code in yyerrlab reads:
+
+      if (yychar <= YYEOF)
+       {
+         /* Return failure if at end of input.  */
+         if (yychar == YYEOF)
+           YYABORT;
+       }
+
+There are only two yychar that can be <= YYEOF: YYEMPTY and YYEOF.
+But I can't produce the situation where yychar is YYEMPTY here, is it
+really possible?  The test suite does not exercise this case.
+
+This shows that it would be interesting to manage to install skeleton
+coverage analysis to the test suite.
+
+** Table definitions
+It should be very easy to factor the definition of the various tables,
+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.
+
+* 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
 
 
 * Header guards
 


@@ -73,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