-*- outline -*-
+* 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?
find something clean (not like YYLSP_NEEDED...).
+* Installation
+
* 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,
-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.
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
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
* 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:
Show reductions.
* Broken options ?
-** %no-parser
** %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
-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
** Adjust the skeletons
Import the skeletons for C and C++.
-** Improve the skeletons
-Have them support yysymprint, yydestruct and so forth.
-
* Precedence
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.
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
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.
-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
-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
-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/>.
projects / bison.git / blobdiff