tests: please C90 compilers

[bison.git] / TODO

diff --git a/TODO b/TODO
index a44f64ece477177531dc7e42dd733d5b37d12751..18c8999553c871f85db03bfc893155c952bec27a 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,33 +1,166 @@
--*- outline -*-
+* 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.

 
 

-* Header guards
+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

 
 

-From Franc,ois: should we keep the directory part in the CPP guard?
+Also, the underscore in print_graph.[ch] isn't very fitting considering
+the dashes in the other filenames.

 
 

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

 
 

-* Yacc.c: CPP Macros
+** m4 names
+b4_shared_declarations is no longer what it is.  Make it
+b4_parser_declaration for instance.

 
 

-Do some people use YYPURE, YYLSP_NEEDED like we do in the test suite?
-They should not: it is not documented.  But if they need to, let's
-find something clean (not like YYLSP_NEEDED...).
+** 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.

 
 
 
 

-* Documentation
-Before releasing, make sure the documentation ("Understanding your
-parser") refers to the current `output' format.
+    /* 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,
+     // ...
+   };
+
+
+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:

 
 

-* lalr1.cc
-** vector
-Move to using vector, drop stack.hh.
+  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.

 
 

-** I18n
-Catch up with yacc.c.

 
 * Report
 
 
 * Report
 

+** Figures
+Some statistics about the grammar and the parser would be useful,
+especially when asking the user to send some information about the
+grammars she is working on.  We should probably also include some
+information about the variables (I'm not sure for instance we even
+specify what LR variant was used).
+

 **  GLR
 How would Paul like to display the conflicted actions?  In particular,
 **  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.
 


@@ -47,39 +180,17 @@ 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
-
-** Labeling the symbols
-Have a look at the Lemon parser generator: instead of $1, $2 etc. they
-can name the values.  This is much more pleasant.  For instance:
-
-       exp (res): exp (a) '+' exp (b) { $res = $a + $b; };
-
-I love this.  I have been bitten too often by the removal of the
-symbol, and forgetting to shift all the $n to $n-1.  If you are
-unlucky, it compiles...
-
-But instead of using $a etc., we can use regular variables.  And
-instead of using (), I propose to use `:' (again).  Paul suggests
-supporting `->' in addition to `:' to separate LHS and RHS. In other
-words:
-
-       r:exp -> a:exp '+' b:exp { r = a + b; };
-
-That requires an significant improvement of the grammar parser.  Using
-GLR would be nice.  It also requires that Bison know the type of the
-symbols (which will be useful for %include anyway).  So we have some
-time before...
-
-Note that there remains the problem of locations: `@r'?

 
 

+* Extensions

 
 ** $-1
 We should find a means to provide an access to values deep in the
 stack.  For instance, instead of
 
 
 ** $-1
 We should find a means to provide an access to values deep in the
 stack.  For instance, instead of
 

-       baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }
+        baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }

 
 we should be able to have:
 
 
 we should be able to have:
 


@@ -87,32 +198,6 @@ we should be able to have:
 
 Or something like this.
 
 
 Or something like this.
 

-** yysymprint interface
-It should be improved, in particular when using Bison features such as
-locations, and YYPARSE_PARAMS.  For the time being, it is almost
-recommended to yyprint to steal internal variables...
-
-** Several %unions
-I think this is a pleasant (but useless currently) feature, but in the
-future, I want a means to %include other bits of grammars, and _then_
-it will be important for the various bits to define their needs in
-%union.
-
-When implementing multiple-%union support, bare the following in mind:
-
-- when --yacc, this must be flagged as an error.  Don't make it fatal
-  though.
-
-- The #line must now appear *inside* the definition of yystype.
-  Something like
-
-       {
-       #line 12 "foo.y"
-         int ival;
-       #line 23 "foo.y"
-         char *sval;
-       }
-

 ** %if and the like
 It should be possible to have %if/%else/%endif.  The implementation is
 not clear: should it be lexical or syntactic.  Vadim Maslow thinks it
 ** %if and the like
 It should be possible to have %if/%else/%endif.  The implementation is
 not clear: should it be lexical or syntactic.  Vadim Maslow thinks it


@@ -120,9 +205,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


@@ -141,13 +223,13 @@ XML output for GNU Bison
 * Unit rules
 Maybe we could expand unit rules, i.e., transform
 
 * Unit rules
 Maybe we could expand unit rules, i.e., transform
 

-       exp: arith | bool;
-       arith: exp '+' exp;
-       bool: exp '&' exp;
+        exp: arith | bool;
+        arith: exp '+' exp;
+        bool: exp '&' exp;

 
 into
 
 
 into
 

-       exp: exp '+' exp | exp '&' exp;
+        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
 
 when there are no actions.  This can significantly speed up some
 grammars.  I can't find the papers.  In particular the book `LR


@@ -163,92 +245,27 @@ this issue.  Does anybody have it?
 Some history of Bison and some bibliography would be most welcome.
 Are there any Texinfo standards for bibliography?
 
 Some history of Bison and some bibliography would be most welcome.
 Are there any Texinfo standards for bibliography?
 

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

-       Currently Bison assumes 8-bit bytes (i.e. that UCHAR_MAX is
-       255).  It also assumes that the 8-bit character encoding is
-       the same for the invocation of 'bison' as it is for the
-       invocation of 'cc', but this is not necessarily true when
-       people run bison on an ASCII host and then use cc on an EBCDIC
-       host.  I don't think these topics are worth our time
-       addressing (unless we find a gung-ho volunteer for EBCDIC or
-       PDP-10 ports :-) but they should probably be documented
-       somewhere.
-
-       More importantly, Bison does not currently allow NUL bytes in
-       tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
-       the source code.  This should get fixed.
+        Currently Bison assumes 8-bit bytes (i.e. that UCHAR_MAX is
+        255).  It also assumes that the 8-bit character encoding is
+        the same for the invocation of 'bison' as it is for the
+        invocation of 'cc', but this is not necessarily true when
+        people run bison on an ASCII host and then use cc on an EBCDIC
+        host.  I don't think these topics are worth our time
+        addressing (unless we find a gung-ho volunteer for EBCDIC or
+        PDP-10 ports :-) but they should probably be documented
+        somewhere.

 
 

-* --graph
-Show reductions.       []
+        More importantly, Bison does not currently allow NUL bytes in
+        tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
+        the source code.  This should get fixed.

 
 * Broken options ?
 
 * Broken options ?

-** %no-parser          []
-** %token-table                []
-** Skeleton strategy.  []
-Must we keep %no-parser?
-            %token-table?
-
-* src/print_graph.c
-Find the best graph parameters.        []
-
-* doc/bison.texinfo
-** Update
-informations about ERROR_VERBOSE.      []
-** Add explanations about
-skeleton muscles.      []
-%skeleton.             []
-
-* testsuite
-** tests/pure-parser.at        []
-New tests.
-
-* 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.
-
-** Keeping the conflicted actions
-First, analyze the differences between byacc and btyacc (I'm referring
-to the executables).  Find where the conflicts are preserved.
-
-** Compare with the GLR tables
-See how isomorphic the way BTYacc and the way the GLR adjustments in
-Bison are compatible.  *As much as possible* one should try to use the
-same implementation in the Bison executables.  I insist: it should be
-very feasible to use the very same conflict tables.
-
-** Adjust the skeletons
-Import the skeletons for C and C++.
-
-** Improve the skeletons
-Have them support yysymprint, yydestruct and so forth.
-
+** %token-table
+** Skeleton strategy
+Must we keep %token-table?

 
 * Precedence
 
 
 * Precedence
 


@@ -257,18 +274,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.


@@ -297,20 +302,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


@@ -339,27 +330,47 @@ 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.
+
+* Complaint submessage indentation.
+We already have an implementation that works fairly well for named
+reference messages, but it would be nice to use it consistently for all
+submessages from Bison.  For example, the "previous definition"
+submessage or the list of correct values for a %define variable might
+look better with indentation.
+
+However, the current implementation makes the assumption that the
+location printed on the first line is not usually much shorter than the
+locations printed on the submessage lines that follow.  That assumption
+may not hold true as often for some kinds of submessages especially if
+we ever support multiple grammar files.
+
+Here's a proposal for how a new implementation might look:
+
+  http://lists.gnu.org/archive/html/bison-patches/2009-09/msg00086.html
+
+
+Local Variables:
+mode: outline
+coding: utf-8
+End:

 
 -----
 
 
 -----
 

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

 
 

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

 
 

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

 
 

-GNU 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/>.