find something clean (not like YYLSP_NEEDED...).
-* readpipe
-
-It should be replaced to avoid tmp files and to improve portability.
-Also, as it is it does not call error () when execve fails, and
-therefore, running M4='m4 --version' bison will silently fail instead
-of:
-
- bison: cannot run m4 --version: No such file or directory
-
-BTW: I would really like to be able to pass arguments to m4...
-
-
-* URGENT: Documenting C++ output
-Write a first documentation for C++ output.
-
+* Installation
* Documentation
-Before releasing, make sure the documentation refers to the current
-`output' format.
-
-
-* Error messages
-Some are really funky. For instance
-
- type clash (`%s' `%s') on default action
-
-is really weird. Revisit them all.
+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.
-* read_pipe.c
-This is not portable to DOS for instance. Implement a more portable
-scheme. Sources of inspiration include GNU diff, and Free Recode.
-
-
-* value_components_used
-Was defined but not used: where was it coming from? It can't be to
-check if %union is used, since the user is free to $<foo>n on her
-union, doesn't she?
-
-
-* GLR & C++
-Currently, the GLR parser cannot compile with a C++ compiler.
-
+** 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 lookahead, 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
-** yyerror, yysymprint interface
-It should be improved, in particular when using Bison features such as
-locations, and YYPARSE_PARAMS. For the time being, it is recommended
-to #define yyerror and yyprint to steal internal variables...
+** 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; };
-** 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.
+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...
-When implementing multiple-%union support, bare the following in mind:
+Note that there remains the problem of locations: `@r'?
-- 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
+** $-1
+We should find a means to provide an access to values deep in the
+stack. For instance, instead of
- {
- #line 12 "foo.y"
- int ival;
- #line 23 "foo.y"
- char *sval;
- }
+ baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }
+
+we should be able to have:
+
+ foo($foo) bar($bar) baz($bar): qux($qux) { $baz = $foo + $bar + $qux; }
+
+Or something like this.
+
+** %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
+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.
+
+** -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
+that they seem to be quite orthogonal to the parsing technique, and
+seem to depend mostly on the possibility to have some code triggered
+for each reduction. As a matter of fact, such hooks could also be
+used to generate the yydebug traces. Some generic scheme probably
+exists in there.
+
+XML output for GNU Bison and gcc
+ http://www.cs.may.ie/~jpower/Research/bisonXML/
+
+XML output for GNU Bison
+ http://yaxx.sourceforge.net/
* Unit rules
Maybe we could expand unit rules, i.e., transform
* 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>
-
-Sébastien 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:
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.
* --graph
-Show reductions. []
+Show reductions.
* Broken options ?
-** %no-lines [ok]
-** %no-parser []
-** %pure-parser []
-** %token-table []
-** Options which could use parse_dquoted_param ().
-Maybe transferred in lex.c.
-*** %skeleton [ok]
-*** %output []
-*** %file-prefix []
-*** %name-prefix []
-
-** Skeleton strategy. []
-Must we keep %no-parser?
- %token-table?
-*** New skeletons. []
+** %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.
-
-* input synclines
-Some users create their foo.y files, and equip them with #line. Bison
-should recognize these, and preserve them.
+Find the best graph parameters.
* BTYacc
-See if we can integrate backtracking in Bison. Contact the BTYacc
-maintainers.
+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
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,
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 Free Software Foundation, Inc.
+Copyright (C) 2001, 2002, 2003, 2004, 2006 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
+Bison 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.
-GNU Bison is distributed in the hope that it will be useful,
+Bison 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., 59 Temple Place - Suite 330,
-Boston, MA 02111-1307, USA.
+the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+Boston, MA 02110-1301, USA.
projects / bison.git / blobdiff