* src/output.c (prepare_actions): Free `tally' and `width'.

[bison.git] / TODO

diff --git a/TODO b/TODO
index 840580d1188cd7e9052c39d6683fe3c9d9d99f66..9750583007fa39da6b42614a8d6f68a26523cf5d 100644 (file)
--- a/TODO
+++ b/TODO
@@ -3,6 +3,16 @@
 * URGENT: Documenting C++ output
 Write a first documentation for C++ output.
 
+* Report and GLR
+How would Paul like to display the conflicted actions?  In particular,
+what when two reductions are possible on a given lookahead, but one is
+part of $default.  Should we make the two reductions explicit, or just
+keep $default?  See the following point.
+
+* Report and Disabled Reductions
+See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
+what we want to do.
+
 * 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
@@ -16,7 +26,9 @@ 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, Meta `Start'...).
-Complete the glossary (item, axiom, ?).
+Complete the glossary (item, axiom, ?).  Should we also rename `$'?
+BYacc uses `$end'.  `$eof' is attracting, but after all we may be
+parsing a string, a stream etc.
 
 * Error messages
 Some are really funky.  For instance
@@ -26,11 +38,11 @@ Some are really funky.  For instance
 is really weird.  Revisit them all.
 
 * 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?
+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
+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.
@@ -248,19 +260,19 @@ the parser with a means to create the (visual) parse tree.
 
 Copyright (C) 2001, 2002 Free Software Foundation, Inc.
 
-This file is part of GNU Autoconf.
+This file is part of GNU Bison.
 
-GNU Autoconf is free software; you can redistribute it and/or modify
+GNU Bison is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; either version 2, or (at your option)
 any later version.
 
-GNU Autoconf is distributed in the hope that it will be useful,
+GNU Bison is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 
 You should have received a copy of the GNU General Public License
-along with autoconf; see the file COPYING.  If not, write to
+along with Bison; see the file COPYING.  If not, write to
 the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 Boston, MA 02111-1307, USA.