Regen.

[bison.git] / TODO

diff --git a/TODO b/TODO
index 567e5b7365af7698412091729c4e7844ce0aa56d..14bd676f20c3ccac8de849a7460a86adf61a277e 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,49 +1,39 @@
 -*- outline -*-
 
 -*- 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"
-       ...
-       %}
-
-       %union {
-         unsigned long int num;
-         enum operator op;
-         struct expression *exp;
-       }
-
-       %{
-       ...
-       static int yylex PARAMS ((YYSTYPE *lval, const char **pexp));
-       ...
-       %}
-
-Where the first part defines struct expression, the second uses it to
-define YYSTYPE, and the last uses YYSTYPE.  Only this order is valid.
+* 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...

 
 

-Note that we have the same problem with GCC.
+* documentation
+Explain $axiom (and maybe change its name: BTYacc names it `goal',
+byacc `$accept', probably based on AT&T Yacc).  Complete the glossary
+(item, axiom, ?).

 
 

-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:
 
 
 When implementing multiple-%union support, bare the following in mind:
 


@@ -60,6 +50,10 @@ When implementing multiple-%union support, bare the following in mind:
          char *sval;
        }
 
          char *sval;
        }
 

+* --report=conflict-path
+Provide better assistance for understanding the conflicts by providing
+a sample text exhibiting the (LALR) ambiguity.
+

 * Coding system independence
 Paul notes:
 
 * Coding system independence
 Paul notes:
 


@@ -73,36 +67,6 @@ Paul notes:
        PDP-10 ports :-) but they should probably be documented
        somewhere.
 
        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
-   ...
-
-> I'm in favor of
->
-> %token FOO 256
-> %token BAR 257
->
-> and Bison moves error into 258.
-
-Yes, I think that's a valid extension too, if the user doesn't define
-the token number for error.
-

 * Output directory
 Akim:
 
 * Output directory
 Akim:
 


@@ -212,11 +176,6 @@ 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 '('
 
 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.
 * 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.


@@ -238,7 +197,6 @@ Show reductions.    []
 ** %no-lines           [ok]
 ** %no-parser          []
 ** %pure-parser                []
 ** %no-lines           [ok]
 ** %no-parser          []
 ** %pure-parser                []

-** %semantic-parser    []

 ** %token-table                []
 ** Options which could use parse_dquoted_param ().
 Maybe transfered in lex.c.
 ** %token-table                []
 ** Options which could use parse_dquoted_param ().
 Maybe transfered in lex.c.


@@ -339,55 +297,13 @@ 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.
 
 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.

 
 

+* Parsing grammars
+Rewrite the reader in Flex/Bison.  There will be delicate parts, in
+particular, expect the scanner to be hard to write.  Many interesting
+features cannot be implemented without such a new reader.

 
 * $undefined
 From Hans:
 
 * $undefined
 From Hans:


@@ -411,6 +327,18 @@ $<type_name>$ = $<type_name>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).
 
 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
 * Pre and post actions.
 From: Florian Krohm <florian@edamail.fishkill.ibm.com>
 Subject: YYACT_EPILOGUE