--*- outline -*-
-
-* URGENT: Documenting C++ output
-Write a first documentation for C++ output.
-
-* value_components_used
-Was defined but not used: where was it coming from? It can't be to
-check if %union is used, since the user is free to $<foo>n on her
-union, doesn't she?
-
-* yyerror, yyprint interface
-It should be improved, in particular when using Bison features such as
-locations, and YYPARSE_PARAMS. For the time being, it is recommended
-to #define yyerror and yyprint to steal internal variables...
-
-* documentation
-Explain $axiom (and maybe change its name: BTYacc names it `goal',
-byacc `$accept', probably based on AT&T Yacc). Complete the glossary
-(item, axiom, ?).
-
-* report documentation
-Extend with error. The hard part will probably be finding the right
-rule so that a single state does not exhibit to many yet undocumented
-``features''. Maybe an empty action ought to be presented too. Shall
-we try to make a single grammar with all these features, or should we
-have several very small grammars?
-
-* documentation
-Some history of Bison and some bibliography would be most welcome.
-Are there any Texinfo standards for bibliography?
+* Short term
+** Graphviz display code thoughts
+The code for the --graph option is over two files: print_graph, and
+graphviz. This is because Bison used to also produce VCG graphs, but since
+this is no longer true, maybe we could consider these files for fusion.
+
+An other consideration worth noting is that print_graph.c (correct me if I
+am wrong) should contain generic functions, whereas graphviz.c and other
+potential files should contain just the specific code for that output
+format. It will probably prove difficult to tell if the implementation is
+actually generic whilst only having support for a single format, but it
+would be nice to keep stuff a bit tidier: right now, the construction of the
+bitset used to show reductions is in the graphviz-specific code, and on the
+opposite side we have some use of \l, which is graphviz-specific, in what
+should be generic code.
+
+Little effort seems to have been given to factoring these files and their
+rint{,-xml} counterpart. We would very much like to re-use the pretty format
+of states from .output for the graphs, etc.
+
+Also, the underscore in print_graph.[ch] isn't very fitting considering the
+dashes in the other filenames.
+
+Since graphviz dies on medium-to-big grammars, maybe consider an other tool?
+
+** push-parser
+Check it too when checking the different kinds of parsers. And be
+sure to check that the initial-action is performed once per parsing.
+
+** m4 names
+b4_shared_declarations is no longer what it is. Make it
+b4_parser_declaration for instance.
+
+** yychar in lalr1.cc
+There is a large difference bw maint and master on the handling of
+yychar (which was removed in lalr1.cc). See what needs to be
+back-ported.
+
+
+ /* User semantic actions sometimes alter yychar, and that requires
+ that yytoken be updated with the new translation. We take the
+ approach of translating immediately before every use of yytoken.
+ One alternative is translating here after every semantic action,
+ but that translation would be missed if the semantic action
+ invokes YYABORT, YYACCEPT, or YYERROR immediately after altering
+ yychar. In the case of YYABORT or YYACCEPT, an incorrect
+ destructor might then be invoked immediately. In the case of
+ YYERROR, subsequent parser actions might lead to an incorrect
+ destructor call or verbose syntax error message before the
+ lookahead is translated. */
+
+ /* Make sure we have latest lookahead translation. See comments at
+ user semantic actions for why this is necessary. */
+ yytoken = yytranslate_ (yychar);
+
+
+** 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,
+ // ...
+ };
projects / bison.git / blobdiff