* 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 $<foo>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
+Before releasing, make sure the documentation refers to the current
+`output' format.
-* 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
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?
+* 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?
+
+
+* 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
+part of $default. Should we make the two reductions explicit, or just
+keep $default? See the following point.
+
+** Disabled Reductions
+See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
+what we want to do.
-* Several %unions
+** 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
+presented too. Shall we try to make a single grammar with all these
+features, or should we have several very small grammars?
+
+** --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.
+
+
+* Extentions
+
+** 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...
+
+** 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
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
`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.
+* Documentation
+
+** History/Bibliography
+Some history of Bison and some bibliography would be most welcome.
+Are there any Texinfo standards for bibliography?
+
+
+
+
+* 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.
+
+
* --graph
Show reductions. []
** tests/pure-parser.at []
New tests.
-* Debugging parsers
-
-From Greg McGary:
-
-akim demaille <akim.demaille@epita.fr> writes:
-
-> With great pleasure! Nonetheless, things which are debatable
-> (or not, but just `big') should be discuss in `public': something
-> like help- or bug-bison@gnu.org is just fine. Jesse and I are there,
-> but there is also Jim and some other people.
-
-I have no idea whether it qualifies as big or controversial, so I'll
-just summarize for you. I proposed this change years ago and was
-surprised that it was met with utter indifference!
-
-This debug feature is for the programs/grammars one develops with
-bison, not for debugging bison itself. I find that the YYDEBUG
-output comes in a very inconvenient format for my purposes.
-When debugging gcc, for instance, what I want is to see a trace of
-the sequence of reductions and the line#s for the semantic actions
-so I can follow what's happening. Single-step in gdb doesn't cut it
-because to move from one semantic action to the next takes you through
-lots of internal machinery of the parser, which is uninteresting.
-
-The change I made was to the format of the debug output, so that it
-comes out in the format of C error messages, digestible by emacs
-compile mode, like so:
-
-grammar.y:1234: foo: bar(0x123456) baz(0x345678)
-
-where "foo: bar baz" is the reduction rule, whose semantic action
-appears on line 1234 of the bison grammar file grammar.y. The hex
-numbers on the rhs tokens are the parse-stack values associated with
-those tokens. Of course, yytype might be something totally
-incompatible with that representation, but for the most part, yytype
-values are single words (scalars or pointers). In the case of gcc,
-they're most often pointers to tree nodes. Come to think of it, the
-right thing to do is to make the printing of stack values be
-user-definable. It would also be useful to include the filename &
-line# of the file being parsed, but the main filename & line# should
-continue to be that of grammar.y
-
-Anyway, this feature has saved my life on numerous occasions. The way
-I customarily use it is to first run bison with the traces on, isolate
-the sequence of reductions that interests me, put those traces in a
-buffer and force it into compile-mode, then visit each of those lines
-in the grammar and set breakpoints with C-x SPACE. Then, I can run
-again under the control of gdb and stop at each semantic action.
-With the hex addresses of tree nodes, I can inspect the values
-associated with any rhs token.
-
-You like?
-
* input synclines
Some users create their foo.y files, and equip them with #line. Bison
should recognize these, and preserve them.
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.
+** 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 adjustements 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++.
+
+** Improve the skeletons
+Have them support yysymprint, yydestruct and so forth.
+
* Precedence
+
+** Partial order
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.
+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.
+
+
* $undefined
From Hans:
- If the Bison generated parser experiences an undefined number in the
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
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
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
Copyright (C) 2001, 2002 Free Software Foundation, Inc.
-This file is part of GNU Autoconf.
+This file is part of GNU Bison.
-GNU Autoconf is free software; you can redistribute it and/or modify
+GNU 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 Autoconf is distributed in the hope that it will be useful,
+GNU 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 autoconf; see the file COPYING. If not, write to
+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.
projects / bison.git / blobdiff