--*- outline -*-
+* Short term
+** Variable names.
+What should we name `variant' and `lex_symbol'?
+
+** Use b4_symbol in all the skeleton
+Move its definition in the more standard places and deploy it in other
+skeletons. 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
+
+
+** 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.
+
+* Various
+** Warnings
+Warnings about type tags that are used in printer and dtors, but not
+for symbols?
+
+** 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:
+
+ 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?
+
+** 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
+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?
+From Franรงois: should we keep the directory part in the CPP guard?
* Yacc.c: CPP Macros
find something clean (not like YYLSP_NEEDED...).
-* 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.
-* lalr1.cc
-** vector
-Move to using vector, drop stack.hh.
-
-** I18n
-Catch up with yacc.c.
-
* 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
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
- baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }
+ baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }
we should be able to have:
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
* 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
- 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
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.
-** 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:
- 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.
* 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.
+
+* 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 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.
-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