+move to partial orders (sounds like series/parallel orders to me).
+
+This will be possible with a Bison parser for the grammar, as it will
+make it much easier to extend the grammar.
+
+** Correlation b/w precedence and associativity
+Also, I fail to understand why we have to assign the same
+associativity to operators with the same precedence. For instance,
+why can't I decide that the precedence of * and / is the same, but the
+latter is nonassoc?
+
+If there is really no profound motivation, we should find a new syntax
+to allow specifying this.
+
+** RR conflicts
+See if we can use precedence between rules to solve RR conflicts. See
+what POSIX says.
+
+
+* $undefined
+From Hans:
+- If the Bison generated parser experiences an undefined number in the
+character range, that character is written out in diagnostic messages, an
+addition to the $undefined value.
+
+Suggest: Change the name $undefined to undefined; looks better in outputs.
+
+
+* Default Action
+From Hans:
+- For use with my C++ parser, I transported the "switch (yyn)" statement
+that Bison writes to the bison.simple skeleton file. This way, I can remove
+the current default rule $$ = $1 implementation, which causes a double
+assignment to $$ which may not be OK under C++, replacing it with a
+"default:" part within the switch statement.
+
+Note that the default rule $$ = $1, when typed, is perfectly OK under C,
+but in the C++ implementation I made, this rule is different from
+$<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.
+
+
+* 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
+To: bug-bison@gnu.org
+X-Sent: 1 week, 4 days, 14 hours, 38 minutes, 11 seconds ago
+
+The other day I had the need for explicitly building the parse tree. I
+used %locations for that and defined YYLLOC_DEFAULT to call a function
+that returns the tree node for the production. Easy. But I also needed
+to assign the S-attribute to the tree node. That cannot be done in
+YYLLOC_DEFAULT, because it is invoked before the action is executed.
+The way I solved this was to define a macro YYACT_EPILOGUE that would
+be invoked after the action. For reasons of symmetry I also added
+YYACT_PROLOGUE. Although I had no use for that I can envision how it
+might come in handy for debugging purposes.
+All is needed is to add
+
+#if YYLSP_NEEDED
+ YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen, yyloc, (yylsp - yylen));
+#else
+ YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen);
+#endif
+
+at the proper place to bison.simple. Ditto for YYACT_PROLOGUE.
+
+I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
+to bison. If you're interested, I'll work on a patch.
projects / bison.git / blobdiff