Merge branch 'maint'

[bison.git] / TODO

diff --git a/TODO b/TODO
index a9ec30838b565d201ad35ff8021a92f8e9c5a5ed..40127468d04b52dc2e6b453248c774fc50425b53 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,11 +1,47 @@
--*- outline -*-
-

 * Short term
 * 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
+** 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);
+
+
+** $ 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.
+
+** 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.


@@ -15,8 +51,6 @@ 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
 
 
 <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
 ** 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


@@ -38,24 +72,29 @@ as lr0.cc, why upper case?
 ** bench several bisons.
 Enhance bench.pl with %b to run different bisons.
 
 ** 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
 * 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?
 
 ** 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:
 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:


@@ -79,62 +118,15 @@ so both 256 and 257 are "mysterious".
   "\"end of command\"", "error", "$undefined", "\"=\"", "\"break\"",
 
 
   "\"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)
 ** yychar == yyempty_
 The code in yyerrlab reads:
 
       if (yychar <= YYEOF)

-       {
-         /* Return failure if at end of input.  */
-         if (yychar == YYEOF)
-           YYABORT;
-       }
+        {
+          /* 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
 
 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


@@ -157,33 +149,19 @@ management is performed once instead of three times).  I suggest that
 we do the same in yacc.c.
 
 ** yysyntax_error
 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?
+The code bw glr.c and yacc.c is really alike, we can certainly factor
+some parts.

 
 
 
 

-* Yacc.c: CPP Macros
-
-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...).
-
-
-* Installation
-
-* Documentation
-Before releasing, make sure the documentation ("Understanding your
-parser") refers to the current `output' format.
-

 * 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,
 what when two reductions are possible on a given lookahead token, but one is
 **  GLR
 How would Paul like to display the conflicted actions?  In particular,
 what when two reductions are possible on a given lookahead token, but one is


@@ -212,36 +190,11 @@ DeRemer and Penello: they already provide the algorithm.
 
 * Extensions
 
 
 * 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'?
-
-

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


@@ -274,13 +227,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


@@ -296,27 +249,22 @@ 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.
-
-

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

 
 * --graph
 Show reductions.
 
 * --graph
 Show reductions.


@@ -326,29 +274,6 @@ Show reductions.
 ** Skeleton strategy
 Must we keep %token-table?
 
 ** Skeleton strategy
 Must we keep %token-table?
 

-* BTYacc
-See if we can integrate backtracking in Bison.  Charles-Henri de
-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
-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++.
-
-

 * Precedence
 
 ** Partial order
 * Precedence
 
 ** Partial order


@@ -415,10 +340,32 @@ to bison. If you're interested, I'll work on a patch.
 * Better graphics
 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, 2006, 2008 Free Software Foundation,
-Inc.
+Copyright (C) 2001-2004, 2006, 2008-2012 Free Software Foundation, Inc.

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