* data/bison.simple (b4_token_enum): New.

[bison.git] / TODO

diff --git a/TODO b/TODO
index 27d2c0844d3472696fae6e3bc6a8a8b9c81b25c4..a43659b4a4f06f9005e2ccaf3c27fb4202ae8d35 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,49 +1,10 @@
 -*- outline -*-
 
-
-* URGENT: Prologue
-The %union is declared after the user C declarations. It can be
-a problem if YYSTYPE is declared after the user part.
-
-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.
-
-Note that we have the same problem with GCC.
-
-I suggest splitting the prologue into pre-prologue and post-prologue.
-The reason is that:
-
-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)
-
-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:
 
@@ -60,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:
 
@@ -98,36 +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
-   ...
-
-> 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:
 
@@ -263,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.