find something clean (not like YYLSP_NEEDED...).
-* URGENT: Documenting C++ output
-Write a first documentation for C++ output.
-
-
* 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.
-* GLR & C++
-Currently, the GLR parser cannot compile with a C++ compiler.
-
+** I18n
+Catch up with yacc.c.
* Report
* Extensions
-** %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
+** 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:
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