update.

[bison.git] / TODO

diff --git a/TODO b/TODO
index e94652cd35f24d50231813ebc54bf0ca3624d22d..bc474d21aee7183e7eeada910dd8e17485e51910 100644 (file)
--- a/TODO
+++ b/TODO
@@ -34,26 +34,6 @@ 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:
 
@@ -289,40 +269,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.
 
-* 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.
+This will be possible with a Bison parser for the grammar, as it will
+make it much easier to extend the grammar.
 
-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...)
+* 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.
 
 * Presentation of the report file
 From: "Baum, Nathan I" <s0009525@chelt.ac.uk>
@@ -338,7 +291,6 @@ 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.)
 
-
 * $undefined
 From Hans:
 - If the Bison generated parser experiences an undefined number in the
@@ -361,6 +313,21 @@ $<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).
 
+Note: Robert Anisko handles this.  He knows how to do it.
+
+* Documenting C++ output
+Write a first documentation for C++ output.
+
+* 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