-*- outline -*- * URGENT: Documenting C++ output Write a first documentation for C++ output. * 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 $n on her union, doesn't she? * yyerror, yyprint 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... * documentation Explain $axiom (and maybe change its name: BTYacc names it `goal', byacc `$accept' probably based on AT&T Yacc, Meta `Start'...). Complete the glossary (item, axiom, ?). * Error messages Some are really funky. For instance type clash (`%s' `%s') on default action is really weird. Revisit them all. * Report documentation Extend with error. The hard part will probably be finding the right rule so that a single state does not exhibit to many yet 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? * Documentation Some history of Bison and some bibliography would be most welcome. Are there any Texinfo standards for bibliography? * 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. When implementing multiple-%union support, bare the following in mind: - 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 { #line 12 "foo.y" int ival; #line 23 "foo.y" char *sval; } * --report=conflict-path Provide better assistance for understanding the conflicts by providing a sample text exhibiting the (LALR) ambiguity. See the paper from DeRemer and Penello: they already provide the algorithm. * 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. * Unit rules Maybe we could expand unit rules, i.e., transform exp: arith | bool; arith: exp '+' exp; bool: exp '&' exp; into 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 parsing: Theory and Practice' is impossible to find, but according to `Parsing Techniques: a Practical Guide', it includes information about this issue. Does anybody have it? * Stupid error messages An example shows it easily: src/bison/tests % ./testsuite -k calc,location,error-verbose -l GNU Bison 1.49a test suite test groups: NUM: FILENAME:LINE TEST-GROUP-NAME KEYWORDS 51: calc.at:440 Calculator --locations --yyerror-verbose 52: calc.at:442 Calculator --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose 54: calc.at:445 Calculator --debug --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose src/bison/tests % ./testsuite 51 -d ## --------------------------- ## ## GNU Bison 1.49a test suite. ## ## --------------------------- ## 51: calc.at:440 ok ## ---------------------------- ## ## All 1 tests were successful. ## ## ---------------------------- ## src/bison/tests % cd ./testsuite.dir/51 tests/testsuite.dir/51 % echo "()" | ./calc 1.2-1.3: parse error, unexpected ')', expecting error or "number" or '-' or '(' * 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. * Memory leaks in the generator A round of memory leak clean ups would be most welcome. Dmalloc, Checker GCC, Electric Fence, or Valgrind: you chose your tool. * --graph Show reductions. [] * Broken options ? ** %no-lines [ok] ** %no-parser [] ** %pure-parser [] ** %token-table [] ** Options which could use parse_dquoted_param (). Maybe transfered in lex.c. *** %skeleton [ok] *** %output [] *** %file-prefix [] *** %name-prefix [] ** Skeleton strategy. [] Must we keep %no-parser? %token-table? *** New skeletons. [] * src/print_graph.c Find the best graph parameters. [] * doc/bison.texinfo ** Update informations about ERROR_VERBOSE. [] ** Add explainations 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. * BTYacc See if we can integrate backtracking in Bison. Contact the BTYacc maintainers. * RR conflicts See if we can use precedence between rules to solve RR conflicts. See what POSIX says. * Precedence It is unfortunate that there is a total order for precedence. It makes it impossible to have modular precedence information. We should move to partial orders. This will be possible with a Bison parser for the grammar, as it will make it much easier to extend the grammar. * $undefined From Hans: - If the Bison generated parser experiences an undefined number in the character range, that character is written out in diagnostic messages, an addition to the $undefined value. Suggest: Change the name $undefined to undefined; looks better in outputs. * Default Action From Hans: - For use with my C++ parser, I transported the "switch (yyn)" statement that Bison writes to the bison.simple skeleton file. This way, I can remove the current default rule $$ = $1 implementation, which causes a double assignment to $$ which may not be OK under C++, replacing it with a "default:" part within the switch statement. Note that the default rule $$ = $1, when typed, is perfectly OK under C, but in the C++ implementation I made, this rule is different from $$ = $1. I therefore think that one should implement 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 Subject: YYACT_EPILOGUE To: bug-bison@gnu.org X-Sent: 1 week, 4 days, 14 hours, 38 minutes, 11 seconds ago The other day I had the need for explicitly building the parse tree. I used %locations for that and defined YYLLOC_DEFAULT to call a function that returns the tree node for the production. Easy. But I also needed to assign the S-attribute to the tree node. That cannot be done in YYLLOC_DEFAULT, because it is invoked before the action is executed. The way I solved this was to define a macro YYACT_EPILOGUE that would be invoked after the action. For reasons of symmetry I also added YYACT_PROLOGUE. Although I had no use for that I can envision how it might come in handy for debugging purposes. All is needed is to add #if YYLSP_NEEDED YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen, yyloc, (yylsp - yylen)); #else YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen); #endif at the proper place to bison.simple. Ditto for YYACT_PROLOGUE. 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. ----- Copyright (C) 2001, 2002 Free Software Foundation, Inc. This file is part of GNU Autoconf. GNU Autoconf 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 Autoconf 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 autoconf; see the file COPYING. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.