+** stack.hh
+Get rid of it. The original idea is nice, but actually it makes
+the code harder to follow, and uselessly different from the other
+skeletons.
+
+** Get rid of fake #lines [Bison: ...]
+Possibly as simple as checking whether the column number is nonnegative.
+
+I have seen messages like the following from GCC.
+
+<built-in>:0: fatal error: opening dependency file .deps/libltdl/argz.Tpo: No such file or directory
+
+
+** Discuss about %printer/%destroy in the case of C++.
+It would be very nice to provide the symbol classes with an operator<<
+and a destructor. Unfortunately the syntax we have chosen for
+%destroy and %printer make them hard to reuse. For instance, the user
+is invited to write something like
+
+ %printer { debug_stream() << $$; } <my_type>;
+
+which is hard to reuse elsewhere since it wants to use
+"debug_stream()" to find the stream to use. The same applies to
+%destroy: we told the user she could use the members of the Parser
+class in the printers/destructors, which is not good for an operator<<
+since it is no longer bound to a particular parser, it's just a
+(standalone symbol).
+
+** Rename LR0.cc
+as lr0.cc, why upper case?
+
+* Various
+** 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?
+
+Also, why don't we output the token name of the error token in the
+output? It is explicitly skipped:
+
+ /* Skip error token and tokens without identifier. */
+ if (sym != errtoken && id)
+
+Of course there are issues with name spaces, but if we disable we have
+something which seems to be more simpler and more consistent instead
+of the special case YYERRCODE.
+
+ enum yytokentype {
+ error = 256,
+ // ...
+ };
+
+
+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\"",
+
+
+** 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.
+
+* 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
+The code bw glr.c and yacc.c is really alike, we can certainly factor
+some parts.
+
projects / bison.git / blobdiff