-*- 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?
+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?
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?
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