]> git.saurik.com Git - bison.git/blobdiff - TODO
build: restore maintainer-push-check
[bison.git] / TODO
diff --git a/TODO b/TODO
index addd135d41d10ab571743c25074663eaaeba4d86..09fce0896dc52bd9163d3c72655c7862898567b9 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,33 +1,63 @@
--*- outline -*-
-
 * Short term
 * Short term
-** Use syntax_error from the scanner?
-This would provide a means to raise syntax error from function called
-from the scanner.  Actually, there is no good solution to report a
-lexical error in general.  Usually they are kept at the scanner level
-only, ignoring the guilty token.  But that might not be the best bet,
-since we don't benefit from the syntactic error recovery.
-
-We still have the possibility to return an invalid token number, which
-does the trick.  But then the error message from the parser is poor
-(something like "unexpected $undefined").  Since the scanner probably
-already reported the error, we should directly enter error-recovery,
-without reporting the error message (i.e., YYERROR's semantics).
-
-Back to lalr1.cc (whose name is now quite unfortunate, since it also
-covers lr and ielr), if we support exceptions from yylex, should we
-propose a lexical_error in addition to syntax_error?  Should they have
-a common root, say parse_error?  Should syntax_error be renamed
-syntactic_error for consistency with lexical_error?
-
-** Variable names.
-What should we name `variant' and `lex_symbol'?
-
-** 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
+** Graphviz display code thoughts
+The code for the --graph option is over two files: print_graph, and
+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.
+
+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.
+
+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
+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);
+
+
+** 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.
 
 ** Get rid of fake #lines [Bison: ...]
 Possibly as simple as checking whether the column number is nonnegative.
@@ -55,21 +85,7 @@ 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.
-
-** 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
 ** 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
@@ -115,53 +131,6 @@ 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:
 
 ** yychar == yyempty_
 The code in yyerrlab reads:
 
@@ -179,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
@@ -196,23 +159,6 @@ we do the same in yacc.c.
 The code bw glr.c and yacc.c is really alike, we can certainly factor
 some parts.
 
 The code bw glr.c and yacc.c is really alike, we can certainly factor
 some parts.
 
-* Header guards
-
-From Franc,ois: should we keep the directory part in the CPP guard?
-
-
-* 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
 
@@ -230,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?
 
@@ -251,31 +197,6 @@ 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
@@ -322,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?
 
 
@@ -335,12 +256,6 @@ 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?
 
-** %printer
-Wow, %printer is not documented.  Clearly mark YYPRINT as obsolete.
-
-* Java, Fortran, etc.
-
-
 * Coding system independence
 Paul notes:
 
 * Coding system independence
 Paul notes:
 
@@ -358,37 +273,11 @@ 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
 Must we keep %token-table?
 
 * Broken options ?
 ** %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
@@ -472,9 +361,15 @@ Here's a proposal for how a new implementation might look:
 
   http://lists.gnu.org/archive/html/bison-patches/2009-09/msg00086.html
 
 
   http://lists.gnu.org/archive/html/bison-patches/2009-09/msg00086.html
 
+
+Local Variables:
+mode: outline
+coding: utf-8
+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.