char *sval;
}
+* Experimental report features
+Decide whether they should be enabled, or optional. For instance, on:
+
+ input:
+ exp
+ | input exp
+ ;
+
+ exp:
+ token1 "1"
+ | token2 "2"
+ | token3 "3"
+ ;
+
+ token1: token;
+ token2: token;
+ token3: token;
+
+the traditional Bison reports:
+
+ state 0
+
+ $axiom -> . input $ (rule 0)
+
+ token shift, and go to state 1
+
+ input go to state 2
+ exp go to state 3
+ token1 go to state 4
+ token2 go to state 5
+ token3 go to state 6
+
+ state 1
+
+ token1 -> token . (rule 6)
+ token2 -> token . (rule 7)
+ token3 -> token . (rule 8)
+
+ "2" reduce using rule 7 (token2)
+ "3" reduce using rule 8 (token3)
+ $default reduce using rule 6 (token1)
+
+while with --trace, i.e., when enabling both the display of non-core
+item sets and the display of lookaheads, Bison now displays:
+
+ state 0
+
+ $axiom -> . input $ (rule 0)
+ input -> . exp (rule 1)
+ input -> . input exp (rule 2)
+ exp -> . token1 "1" (rule 3)
+ exp -> . token2 "2" (rule 4)
+ exp -> . token3 "3" (rule 5)
+ token1 -> . token (rule 6)
+ token2 -> . token (rule 7)
+ token3 -> . token (rule 8)
+
+ token shift, and go to state 1
+
+ input go to state 2
+ exp go to state 3
+ token1 go to state 4
+ token2 go to state 5
+ token3 go to state 6
+
+ state 1
+
+ token1 -> token . ["1"] (rule 6)
+ token2 -> token . ["2"] (rule 7)
+ token3 -> token . ["3"] (rule 8)
+
+ "2" reduce using rule 7 (token2)
+ "3" reduce using rule 8 (token3)
+ $default reduce using rule 6 (token1)
+
+so decide whether this should be an option, or always enabled. I'm in
+favor of making it the default, but maybe we should tune the output to
+distinguish core item sets from non core:
+
+ state 0
+ Core:
+ $axiom -> . input $ (rule 0)
+
+ Derived:
+ input -> . exp (rule 1)
+ input -> . input exp (rule 2)
+ exp -> . token1 "1" (rule 3)
+ exp -> . token2 "2" (rule 4)
+ exp -> . token3 "3" (rule 5)
+ token1 -> . token (rule 6)
+ token2 -> . token (rule 7)
+ token3 -> . token (rule 8)
+
+ token shift, and go to state 1
+
+ input go to state 2
+ exp go to state 3
+ token1 go to state 4
+ token2 go to state 5
+ token3 go to state 6
+
+
+Note that the same questions applies to --graph.
+
* Coding system independence
Paul notes:
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...
+This will be possible with a Bison parser for the grammar, as it will
+make it much easier to extend the grammar.
-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...)
+* 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>
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
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
projects / bison.git / blobdiff