-*- outline -*-
+* URGENT: Documenting C++ output
+Write a first documentation for C++ output.
-* URGENT: Prologue
-The %union is declared after the user C declarations. It can be
-a problem if YYSTYPE is declared after the user part.
+* 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?
-Actually, the real problem seems that the %union ought to be output
-where it was defined. For instance, in gettext/intl/plural.y, we
-have:
-
- %{
- ...
- #include "gettextP.h"
- ...
- %}
+* 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...
- %union {
- unsigned long int num;
- enum operator op;
- struct expression *exp;
- }
+* 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, ?).
- %{
- ...
- static int yylex PARAMS ((YYSTYPE *lval, const char **pexp));
- ...
- %}
+* Error messages
+Some are really funky. For instance
-Where the first part defines struct expression, the second uses it to
-define YYSTYPE, and the last uses YYSTYPE. Only this order is valid.
+ type clash (`%s' `%s') on default action
-Note that we have the same problem with GCC.
+is really weird. Revisit them all.
-I suggest splitting the prologue into pre-prologue and post-prologue.
-The reason is that:
+* 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?
-1. we keep language independance as it is the skeleton that joins the
-two prologues (there is no need for the engine to encode union yystype
-and to output it inside the prologue, which breaks the language
-independance of the generator)
+* Documentation
+Some history of Bison and some bibliography would be most welcome.
+Are there any Texinfo standards for bibliography?
-2. that makes it possible to have several %union in input. 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.
+* 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:
char *sval;
}
-* Language independent actions
-
-Currently bison, the generator, transforms $1, $$ and so forth into
-direct C code, manipulating the stacks. This is problematic, because
-(i) it means that if we want more languages, we need to update the
-generator, and (ii), it forces names everywhere (e.g., the C++
-skeleton would be happy to use other naming schemes, and actually,
-even other accessing schemes).
-
-Therefore we want
-
-1. the generator to replace $1, etc. by M4 macro invocations
- (b4_dollar(1), b4_at(3), b4_dollar_dollar) etc.
-
-2. the skeletons to define these macros.
-
-But currently the actions are double-quoted, to protect them from M4
-evaluation. So we need to:
-
-3. stop quoting them
-
-4. change the [ and ] in the actions into @<:@ and @:>@
-
-5. extend the postprocessor to maps these back onto [ and ].
+* --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:
PDP-10 ports :-) but they should probably be documented
somewhere.
-* Using enums instead of int for tokens.
-Paul suggests:
-
- #ifndef YYTOKENTYPE
- # if defined (__STDC__) || defined (__cplusplus)
- /* Put the tokens into the symbol table, so that GDB and other debuggers
- know about them. */
- enum yytokentype {
- FOO = 256,
- BAR,
- ...
- };
- /* POSIX requires `int' for tokens in interfaces. */
- # define YYTOKENTYPE int
- # endif
- #endif
- #define FOO 256
- #define BAR 257
- ...
-
-* Output directory
-Akim:
-
-| I consider this to be a bug in bison:
-|
-| /tmp % mkdir src
-| /tmp % cp ~/src/bison/tests/calc.y src
-| /tmp % mkdir build && cd build
-| /tmp/build % bison ../src/calc.y
-| /tmp/build % cd ..
-| /tmp % ls -l build src
-| build:
-| total 0
-|
-| src:
-| total 32
-| -rw-r--r-- 1 akim lrde 27553 oct 2 16:31 calc.tab.c
-| -rw-r--r-- 1 akim lrde 3335 oct 2 16:31 calc.y
-|
-|
-| Would it be safe to change this behavior to something more reasonable?
-| Do you think some people depend upon this?
-
-Jim:
-
-Is it that behavior documented?
-If so, then it's probably not reasonable to change it.
-I've Cc'd the automake list, because some of automake's
-rules use bison through $(YACC) -- though I'll bet they
-all use it in yacc-compatible mode.
-
-Pavel:
-
-Hello, Jim and others!
-
-> Is it that behavior documented?
-> If so, then it's probably not reasonable to change it.
-> I've Cc'd the automake list, because some of automake's
-> rules use bison through $(YACC) -- though I'll bet they
-> all use it in yacc-compatible mode.
-
-Yes, Automake currently used bison in Automake-compatible mode, but it
-would be fair for Automake to switch to the native mode as long as the
-processed files are distributed and "missing" emulates bison.
-
-In any case, the makefiles should specify the output file explicitly
-instead of relying on weird defaults.
-
-> | src:
-> | total 32
-> | -rw-r--r-- 1 akim lrde 27553 oct 2 16:31 calc.tab.c
-> | -rw-r--r-- 1 akim lrde 3335 oct 2 16:31 calc.y
-
-This is not _that_ ugly as it seems - with Automake you want to put
-sources where they belong - to the source directory.
-
-> | This is not _that_ ugly as it seems - with Automake you want to put
-> | sources where they belong - to the source directory.
->
-> The difference source/build you are referring to is based on Automake
-> concepts. They have no sense at all for tools such as bison or gcc
-> etc. They have input and output. I do not want them to try to grasp
-> source/build. I want them to behave uniformly: output *here*.
-
-I realize that.
-
-It's unfortunate that the native mode of Bison behaves in a less uniform
-way than the yacc mode. I agree with your point. Bison maintainters may
-want to fix it along with the documentation.
-
-
* Unit rules
Maybe we could expand unit rules, i.e., transform
exp: exp '+' exp | exp '&' exp;
when there are no actions. This can significantly speed up some
-grammars.
+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:
tests/testsuite.dir/51 % echo "()" | ./calc
1.2-1.3: parse error, unexpected ')', expecting error or "number" or '-' or '('
-* 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...
-
* 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.
A round of memory leak clean ups would be most welcome. Dmalloc,
Checker GCC, Electric Fence, or Valgrind: you chose your tool.
-* Memory leaks in the parser
-The same applies to the generated parsers. In particular, this is
-critical for user data: when aborting a parsing, when handling the
-error token etc., we often throw away yylval without giving a chance
-of cleaning it up to the user.
-
* --graph
Show reductions. []
** %no-lines [ok]
** %no-parser []
** %pure-parser []
-** %semantic-parser []
** %token-table []
** Options which could use parse_dquoted_param ().
Maybe transfered in lex.c.
See if we can integrate backtracking in Bison. Contact the BTYacc
maintainers.
-* Automaton report
-Display more clearly the lookaheads for each item.
-
* RR conflicts
See if we can use precedence between rules to solve RR conflicts. See
what POSIX says.
makes it impossible to have modular precedence information. We should
move to partial orders.
-* Parsing grammars
-Rewrite the reader in Bison.
-
-* Problems with aliases
-From: "Baum, Nathan I" <s0009525@chelt.ac.uk>
-Subject: Token Alias Bug
-To: "'bug-bison@gnu.org'" <bug-bison@gnu.org>
-
-I've noticed a bug in bison. Sadly, our eternally wise sysadmins won't let
-us use CVS, so I can't find out if it's been fixed already...
-
-Basically, I made a program (in flex) that went through a .y file looking
-for "..."-tokens, and then outputed a %token
-line for it. For single-character ""-tokens, I reasoned, I could just use
-[%token 'A' "A"]. However, this causes Bison to output a [#define 'A' 65],
-which cppp chokes on, not unreasonably. (And even if cppp didn't choke, I
-obviously wouldn't want (char)'A' to be replaced with (int)65 throughout my
-code.
-
-Bison normally forgoes outputing a #define for a character token. However,
-it always outputs an aliased token -- even if the token is an alias for a
-character token. We don't want that. The problem is in /output.c/, as I
-recall. When it outputs the token definitions, it checks for a character
-token, and then checks for an alias token. If the character token check is
-placed after the alias check, then it works correctly.
-
-Alias tokens seem to be something of a kludge. What about an [%alias "..."]
-command...
-
- %alias T_IF "IF"
-
-Hmm. I can't help thinking... What about a --generate-lex option that
-creates an .l file for the alias tokens used... (Or an option to make a
-gperf file, etc...)
-
-* Presentation of the report file
-From: "Baum, Nathan I" <s0009525@chelt.ac.uk>
-Subject: Token Alias Bug
-To: "'bug-bison@gnu.org'" <bug-bison@gnu.org>
-
-I've also noticed something, that whilst not *wrong*, is inconvienient: I
-use the verbose mode to help find the causes of unresolved shift/reduce
-conflicts. However, this mode insists on starting the .output file with a
-list of *resolved* conflicts, something I find quite useless. Might it be
-possible to define a -v mode, and a -vv mode -- Where the -vv mode shows
-everything, but the -v mode only tells you what you need for examining
-conflicts? (Or, perhaps, a "*** This state has N conflicts ***" marker above
-each state with conflicts.)
-
+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:
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.
+
-----
Copyright (C) 2001, 2002 Free Software Foundation, Inc.
projects / bison.git / blobdiff