xml: also display %empty for empty right-hand sides

[bison.git] / TODO

diff --git a/TODO b/TODO
index e8509e3cfcf74651f579d6d79f472d7ef339c935..09fce0896dc52bd9163d3c72655c7862898567b9 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,16 +1,27 @@
 * Short term
 ** Graphviz display code thoughts
 The code for the --graph option is over two files: print_graph, and
 * Short term
 ** Graphviz display code thoughts
 The code for the --graph option is over two files: print_graph, and

-graphviz. I believe 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.
+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.

 
 

-Little effort factoring seems to have been given to factoring in these files,
-and their print-xml and print counterpart. We would very much like to re-use
-the pretty format of states from .output in the .dot
+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.

 
 

-Also, the underscore in print_graph.[ch] isn't very fitting considering
-the dashes in the other filenames.
+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
 
 ** push-parser
 Check it too when checking the different kinds of parsers.  And be


@@ -43,18 +54,11 @@ back-ported.
     yytoken = yytranslate_ (yychar);
 
 
     yytoken = yytranslate_ (yychar);
 
 

-** $ and others in epilogue
-A stray $ is a warning in the actions, but an error in the epilogue.
-IMHO, it should not even be a warning in the epilogue.
-

 ** 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.
 
 ** 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.
 

-** Variable names.
-What should we name `variant' and `lex_symbol'?
-

 ** Get rid of fake #lines [Bison: ...]
 Possibly as simple as checking whether the column number is nonnegative.
 
 ** Get rid of fake #lines [Bison: ...]
 Possibly as simple as checking whether the column number is nonnegative.
 


@@ -81,9 +85,6 @@ since it is no longer bound to a particular parser, it's just a
 ** Rename LR0.cc
 as lr0.cc, why upper case?
 
 ** Rename LR0.cc
 as lr0.cc, why upper case?
 

-** bench several bisons.
-Enhance bench.pl with %b to run different bisons.
-

 * Various
 ** YYERRCODE
 Defined to 256, but not used, not documented.  Probably the token
 * Various
 ** YYERRCODE
 Defined to 256, but not used, not documented.  Probably the token


@@ -147,12 +148,6 @@ 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.
 
 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
 * From lalr1.cc to yacc.c
 ** Single stack
 Merging the three stacks in lalr1.cc simplified the code, prompted for


@@ -181,13 +176,13 @@ part of $default.  Should we make the two reductions explicit, or just
 keep $default?  See the following point.
 
 ** Disabled Reductions
 keep $default?  See the following point.
 
 ** Disabled Reductions

-See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
+See 'tests/conflicts.at (Defaulted Conflicted Reduction)', and decide

 what we want to do.
 
 ** Documentation
 Extend with error productions.  The hard part will probably be finding
 the right rule so that a single state does not exhibit too many yet
 what we want to do.
 
 ** Documentation
 Extend with error productions.  The hard part will probably be finding
 the right rule so that a single state does not exhibit too many yet

-undocumented ``features''.  Maybe an empty action ought to be
+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?
 
 presented too.  Shall we try to make a single grammar with all these
 features, or should we have several very small grammars?
 


@@ -248,9 +243,9 @@ into
         exp: exp '+' exp | exp '&' exp;
 
 when there are no actions.  This can significantly speed up some
         exp: exp '+' exp | exp '&' exp;
 
 when there are no actions.  This can significantly speed up some

-grammars.  I can't find the papers.  In particular the book `LR
+grammars.  I can't find the papers.  In particular the book 'LR

 parsing: Theory and Practice' is impossible to find, but according to
 parsing: Theory and Practice' is impossible to find, but according to

-`Parsing Techniques: a Practical Guide', it includes information about
+'Parsing Techniques: a Practical Guide', it includes information about

 this issue.  Does anybody have it?
 
 
 this issue.  Does anybody have it?
 
 


@@ -278,9 +273,6 @@ Paul notes:
         tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
         the source code.  This should get fixed.
 
         tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
         the source code.  This should get fixed.
 

-* --graph
-Show reductions.
-

 * Broken options ?
 ** %token-table
 ** Skeleton strategy
 * Broken options ?
 ** %token-table
 ** Skeleton strategy


@@ -377,7 +369,7 @@ End:
 
 -----
 
 
 -----
 

-Copyright (C) 2001-2004, 2006, 2008-2012 Free Software Foundation, Inc.
+Copyright (C) 2001-2004, 2006, 2008-2013 Free Software Foundation, Inc.

 
 This file is part of Bison, the GNU Compiler Compiler.
 
 
 This file is part of Bison, the GNU Compiler Compiler.