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
+
+
+> So, it seems clear that it has to be an additional option :)
+
+Paul:
+
+ There will be further such options in the future, so I'd make
+ them all operands of the --report option. E.g., you could do
+ something like this:
+
+ --report=state --report=lookahead --report=itemset
+ --report=conflict-path
+
+ where "--verbose" is equivalent to "--report=state", and where
+ "--report=conflict-path" reports each path to a conflict
+ state.
+
+ (As a minor point, I prefer avoiding plurals in option names.
+ It's partly for brevity, and partly to avoid wearing out the
+ 's' keys in our keyboards. :-)
+
+To implement this, see in the Fileutils the latest versions of
+argmatch and so forth.
+
+
* 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...
-
-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...
+This will be possible with a Bison parser for the grammar, as it will
+make it much easier to extend the grammar.
- %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