+* Installation
+
+* Documentation
+Before releasing, make sure the documentation ("Understanding your
+parser") refers to the current `output' format.
+
+* lalr1.cc
+** vector
+Move to using vector, drop stack.hh.
+
+* Report
+
+** GLR
+How would Paul like to display the conflicted actions? In particular,
+what when two reductions are possible on a given lookahead token, but one is
+part of $default. Should we make the two reductions explicit, or just
+keep $default? See the following point.
+
+** Disabled Reductions
+See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
+what we want to do.
+
+** Documentation
+Extend with error productions. The hard part will probably be finding
+the right rule so that a single state does not exhibit too many yet
+undocumented ``features''. Maybe an empty action ought to be
+presented too. Shall we try to make a single grammar with all these
+features, or should we have several very small grammars?
+
+** --report=conflict-path
+Provide better assistance for understanding the conflicts by providing
+a sample text exhibiting the (LALR) ambiguity. See the paper from
+DeRemer and Penello: they already provide the algorithm.
+
+** Statically check for potential ambiguities in GLR grammars. See
+<http://www.i3s.unice.fr/~schmitz/papers.html#expamb> for an approach.
+
+
+* Extensions
+
+** Labeling the symbols
+Have a look at the Lemon parser generator: instead of $1, $2 etc. they
+can name the values. This is much more pleasant. For instance:
+
+ exp (res): exp (a) '+' exp (b) { $res = $a + $b; };
+
+I love this. I have been bitten too often by the removal of the
+symbol, and forgetting to shift all the $n to $n-1. If you are
+unlucky, it compiles...
+
+But instead of using $a etc., we can use regular variables. And
+instead of using (), I propose to use `:' (again). Paul suggests
+supporting `->' in addition to `:' to separate LHS and RHS. In other
+words:
+
+ r:exp -> a:exp '+' b:exp { r = a + b; };
+
+That requires an significant improvement of the grammar parser. Using
+GLR would be nice. It also requires that Bison know the type of the
+symbols (which will be useful for %include anyway). So we have some
+time before...
+
+Note that there remains the problem of locations: `@r'?
+
+
+** $-1
+We should find a means to provide an access to values deep in the
+stack. For instance, instead of
+
+ baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }
+
+we should be able to have:
+
+ foo($foo) bar($bar) baz($bar): qux($qux) { $baz = $foo + $bar + $qux; }
+
+Or something like this.
+
+** %if and the like
+It should be possible to have %if/%else/%endif. The implementation is
+not clear: should it be lexical or syntactic. Vadim Maslow thinks it
+must be in the scanner: we must not parse what is in a switched off
+part of %if. Akim Demaille thinks it should be in the parser, so as
+to avoid falling into another CPP mistake.
+
+** -D, --define-muscle NAME=VALUE
+To define muscles via cli. Or maybe support directly NAME=VALUE?
+
+** XML Output
+There are couple of available extensions of Bison targeting some XML
+output. Some day we should consider including them. One issue is
+that they seem to be quite orthogonal to the parsing technique, and
+seem to depend mostly on the possibility to have some code triggered
+for each reduction. As a matter of fact, such hooks could also be
+used to generate the yydebug traces. Some generic scheme probably
+exists in there.
projects / bison.git / blobdiff