* Documentation
-Before releasing, make sure the documentation refers to the current
-`output' format.
+Before releasing, make sure the documentation ("Understanding your
+parser") refers to the current `output' format.
* GLR & C++
* Extensions
-** yyerror, yysymprint interface
+** %destructor
+I think we should document it as experimental, and allow its use in
+the next releases. But we also need to port it to GLR. What about
+lalr1.cc? Well, read what Hans reported, maybe we don't want
+%detructor. On the other hand, there is no reason not to provide it:
+users can avoid its use.
+
+** $foo
+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...
+
+** $-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.
+
+
+** yysymprint interface
It should be improved, in particular when using Bison features such as
-locations, and YYPARSE_PARAMS. For the time being, it is recommended
-to #define yyerror and yyprint to steal internal variables...
+locations, and YYPARSE_PARAMS. For the time being, it is almost
+recommended to yyprint to steal internal variables...
** Several %unions
I think this is a pleasant (but useless currently) feature, but in the