]> git.saurik.com Git - bison.git/blobdiff - TODO
update.
[bison.git] / TODO
diff --git a/TODO b/TODO
index 9f10420b103db020daad0796102dd81310b8c7b9..bc474d21aee7183e7eeada910dd8e17485e51910 100644 (file)
--- a/TODO
+++ b/TODO
@@ -21,31 +21,6 @@ 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 ].
-
 * Coding system independence
 Paul notes:
 
@@ -59,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:
 
@@ -214,7 +169,6 @@ 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.
@@ -315,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.
-
-Alias tokens seem to be something of a kludge. What about an [%alias "..."]
-command...
-
-       %alias T_IF "IF"
+This will be possible with a Bison parser for the grammar, as it will
+make it much easier to extend the grammar.
 
-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>
@@ -364,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
@@ -387,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