]> git.saurik.com Git - bison.git/blobdiff - TODO
* src/symtab.h (SALIAS, SUNDEF): Rename as...
[bison.git] / TODO
diff --git a/TODO b/TODO
index 779cf9e56969c1d8f12a71d8ccac03721de4c331..bc474d21aee7183e7eeada910dd8e17485e51910 100644 (file)
--- a/TODO
+++ b/TODO
@@ -269,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>
@@ -318,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
@@ -341,12 +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