]> git.saurik.com Git - bison.git/blobdiff - TODO
Use the symbol properties to output the printer/destructor for lalr1.cc.
[bison.git] / TODO
diff --git a/TODO b/TODO
index b6e1a20a94a2317be43e78f80731444569d49af3..a9ec30838b565d201ad35ff8021a92f8e9c5a5ed 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,5 +1,169 @@
 -*- outline -*-
 
 -*- outline -*-
 
+* Short term
+** Use b4_symbol in all the skeleton
+Then remove the older system, including the tables generated by
+output.c
+
+** Update the documentation on gnu.org
+
+** 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
+
+
+** Document %define assert
+
+** 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?
+
+** bench several bisons.
+Enhance bench.pl with %b to run different bisons.
+
+** Use b4_symbol everywhere.
+Move its definition in the more standard places and deploy it in other
+skeletons.
+
+* 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?
+
+** YYBACKUP
+There is no test about it, no examples in the doc, and I'm not sure
+what it should look like.  For instance what follows crashes.
+
+  %error-verbose
+  %debug
+  %pure-parser
+  %code {
+  # include <stdio.h>
+  # include <stdlib.h>
+  # include <assert.h>
+
+    static void yyerror (const char *msg);
+    static int yylex (YYSTYPE *yylval);
+  }
+  %%
+  exp:
+    'a'   { printf ("a: %d\n", $1); }
+  | 'b'   { YYBACKUP('a', 123); }
+  ;
+  %%
+  static int
+  yylex (YYSTYPE *yylval)
+  {
+    static char const input[] = "b";
+    static size_t toknum;
+    assert (toknum < sizeof input);
+    *yylval = (toknum + 1) * 10;
+    return input[toknum++];
+  }
+
+  static void
+  yyerror (const char *msg)
+  {
+    fprintf (stderr, "%s\n", msg);
+  }
+
+  int
+  main (void)
+  {
+    yydebug = !!getenv("YYDEBUG");
+    return yyparse ();
+  }
+
+** 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.
+
+** 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
+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?
 * Header guards
 
 From Franc,ois: should we keep the directory part in the CPP guard?
@@ -14,29 +178,15 @@ find something clean (not like YYLSP_NEEDED...).
 
 * Installation
 
 
 * Installation
 
-** Disable installation of yacc.
-
-Add an option to 'configure' that allows people to install Bison
-without installing the yacc wrapper script or the rarely-used little
-yacc library required by Posix.  This is for people who prefer some
-other implementation of yacc.
-
 * Documentation
 Before releasing, make sure the documentation ("Understanding your
 parser") refers to the current `output' format.
 
 * Documentation
 Before releasing, make sure the documentation ("Understanding your
 parser") refers to the current `output' format.
 
-* lalr1.cc
-** vector
-Move to using vector, drop stack.hh.
-
-** I18n
-Catch up with yacc.c.
-
 * Report
 
 **  GLR
 How would Paul like to display the conflicted actions?  In particular,
 * Report
 
 **  GLR
 How would Paul like to display the conflicted actions?  In particular,
-what when two reductions are possible on a given look-ahead token, but one is
+what when two reductions are possible on a given lookahead token, but one is
 part of $default.  Should we make the two reductions explicit, or just
 keep $default?  See the following point.
 
 part of $default.  Should we make the two reductions explicit, or just
 keep $default?  See the following point.
 
@@ -56,6 +206,9 @@ Provide better assistance for understanding the conflicts by providing
 a sample text exhibiting the (LALR) ambiguity.  See the paper from
 DeRemer and Penello: they already provide the algorithm.
 
 a sample text exhibiting the (LALR) ambiguity.  See the paper from
 DeRemer and Penello: they already provide the algorithm.
 
+** Statically check for potential ambiguities in GLR grammars.  See
+<http://www.i3s.unice.fr/~schmitz/papers.html#expamb> for an approach.
+
 
 * Extensions
 
 
 * Extensions
 
@@ -103,9 +256,6 @@ must be in the scanner: we must not parse what is in a switched off
 part of %if.  Akim Demaille thinks it should be in the parser, so as
 to avoid falling into another CPP mistake.
 
 part of %if.  Akim Demaille thinks it should be in the parser, so as
 to avoid falling into another CPP mistake.
 
-** -D, --define-muscle NAME=VALUE
-To define muscles via cli.  Or maybe support directly NAME=VALUE?
-
 ** XML Output
 There are couple of available extensions of Bison targeting some XML
 output.  Some day we should consider including them.  One issue is
 ** XML Output
 There are couple of available extensions of Bison targeting some XML
 output.  Some day we should consider including them.  One issue is
@@ -151,23 +301,6 @@ Are there any Texinfo standards for bibliography?
 * Java, Fortran, etc.
 
 
 * Java, Fortran, etc.
 
 
-** Java
-
-There are a couple of proposed outputs:
-
-- BYACC/J
-  which is based on Byacc.
-  <http://troi.lincom-asg.com/~rjamison/byacc/>
-
-- Bison Java
-  which is based on Bison.
-  <http://www.goice.co.jp/member/mo/hack-progs/bison-java.html>
-
-Sebastien Serrurier (serrur_s@epita.fr) is working on this: he is
-expected to contact the authors, design the output, and implement it
-into Bison.
-
-
 * Coding system independence
 Paul notes:
 
 * Coding system independence
 Paul notes:
 
@@ -189,20 +322,18 @@ Paul notes:
 Show reductions.
 
 * Broken options ?
 Show reductions.
 
 * Broken options ?
-** %no-parser
 ** %token-table
 ** Skeleton strategy
 ** %token-table
 ** Skeleton strategy
-Must we keep %no-parser?  %token-table?
-
-* src/print_graph.c
-Find the best graph parameters.
+Must we keep %token-table?
 
 * BTYacc
 See if we can integrate backtracking in Bison.  Charles-Henri de
 
 * BTYacc
 See if we can integrate backtracking in Bison.  Charles-Henri de
-Boysson <de-boy_c@epita.fr> is working on this, and already has some
-results.  Vadim Maslow, the maintainer of BTYacc was contacted, and we
-stay in touch with him.  Adjusting the Bison grammar parser will be
-needed to support some extra BTYacc features.  This is less urgent.
+Boysson <de-boy_c@epita.fr> has been working on this, but never gave
+the results.
+
+Vadim Maslow, the maintainer of BTYacc was once contacted.  Adjusting
+the Bison grammar parser will be needed to support some extra BTYacc
+features.  This is less urgent.
 
 ** Keeping the conflicted actions
 First, analyze the differences between byacc and btyacc (I'm referring
 
 ** Keeping the conflicted actions
 First, analyze the differences between byacc and btyacc (I'm referring
@@ -217,9 +348,6 @@ very feasible to use the very same conflict tables.
 ** Adjust the skeletons
 Import the skeletons for C and C++.
 
 ** Adjust the skeletons
 Import the skeletons for C and C++.
 
-** Improve the skeletons
-Have them support yysymprint, yydestruct and so forth.
-
 
 * Precedence
 
 
 * Precedence
 
@@ -228,18 +356,6 @@ It is unfortunate that there is a total order for precedence.  It
 makes it impossible to have modular precedence information.  We should
 move to partial orders (sounds like series/parallel orders to me).
 
 makes it impossible to have modular precedence information.  We should
 move to partial orders (sounds like series/parallel orders to me).
 
-This will be possible with a Bison parser for the grammar, as it will
-make it much easier to extend the grammar.
-
-** Correlation b/w precedence and associativity
-Also, I fail to understand why we have to assign the same
-associativity to operators with the same precedence.  For instance,
-why can't I decide that the precedence of * and / is the same, but the
-latter is nonassoc?
-
-If there is really no profound motivation, we should find a new syntax
-to allow specifying this.
-
 ** RR conflicts
 See if we can use precedence between rules to solve RR conflicts.  See
 what POSIX says.
 ** RR conflicts
 See if we can use precedence between rules to solve RR conflicts.  See
 what POSIX says.
@@ -268,20 +384,6 @@ $<type_name>$ = $<type_name>1. I therefore think that one should implement
 a Bison option where every typed default rule is explicitly written out
 (same typed ruled can of course be grouped together).
 
 a Bison option where every typed default rule is explicitly written out
 (same typed ruled can of course be grouped together).
 
-Note: Robert Anisko handles this.  He knows how to do it.
-
-
-* Warnings
-It would be nice to have warning support.  See how Autoconf handles
-them, it is fairly well described there.  It would be very nice to
-implement this in such a way that other programs could use
-lib/warnings.[ch].
-
-Don't work on this without first announcing you do, as I already have
-thought about it, and know many of the components that can be used to
-implement it.
-
-
 * Pre and post actions.
 From: Florian Krohm <florian@edamail.fishkill.ibm.com>
 Subject: YYACT_EPILOGUE
 * Pre and post actions.
 From: Florian Krohm <florian@edamail.fishkill.ibm.com>
 Subject: YYACT_EPILOGUE
@@ -310,28 +412,25 @@ at the proper place to bison.simple. Ditto for YYACT_PROLOGUE.
 I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
 to bison. If you're interested, I'll work on a patch.
 
 I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
 to bison. If you're interested, I'll work on a patch.
 
-* Move to Graphviz
-Well, VCG seems really dead.  Move to Graphviz instead.  Also, equip
-the parser with a means to create the (visual) parse tree.
+* Better graphics
+Equip the parser with a means to create the (visual) parse tree.
 
 -----
 
 
 -----
 
-Copyright (C) 2001, 2002, 2003, 2004, 2006 Free Software Foundation,
+Copyright (C) 2001, 2002, 2003, 2004, 2006, 2008 Free Software Foundation,
 Inc.
 
 This file is part of Bison, the GNU Compiler Compiler.
 
 Inc.
 
 This file is part of Bison, the GNU Compiler Compiler.
 
-Bison is free software; you can redistribute it and/or modify
+This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 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.
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
 
 
-Bison is distributed in the hope that it will be useful,
+This program 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
 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 Bison; see the file COPYING.  If not, write to
-the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
-Boston, MA 02110-1301, USA.
+along with this program.  If not, see <http://www.gnu.org/licenses/>.