(%expect with reduce conflicts): New test.

[bison.git] / TODO

-*- outline -*-

* Header guards

From Franc,ois: should we keep the directory part in the CPP guard?


* Yacc.c: CPP Macros

Do some people use YYPURE, YYLSP_NEEDED like we do in the test suite?
They should not: it is not documented.  But if they need to, let's
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.


* GLR & C++
Currently, the GLR parser cannot compile with a C++ compiler.


* Report

**  GLR
How would Paul like to display the conflicted actions?  In particular,
what when two reductions are possible on a given lookahead, 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.


* 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
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 almost
recommended to yyprint to steal internal variables...

** Several %unions
I think this is a pleasant (but useless currently) feature, but in the
future, I want a means to %include other bits of grammars, and _then_
it will be important for the various bits to define their needs in
%union.

When implementing multiple-%union support, bare the following in mind:

- when --yacc, this must be flagged as an error.  Don't make it fatal
  though.

- The #line must now appear *inside* the definition of yystype.
  Something like

	{
	#line 12 "foo.y"
	  int ival;
	#line 23 "foo.y"
	  char *sval;
	}

** %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?


* Unit rules
Maybe we could expand unit rules, i.e., transform

	exp: arith | bool;
	arith: exp '+' exp;
	bool: exp '&' exp;

into

	exp: exp '+' exp | exp '&' exp;

when there are no actions.  This can significantly speed up some
grammars.  I can't find the papers.  In particular the book `LR
parsing: Theory and Practice' is impossible to find, but according to
`Parsing Techniques: a Practical Guide', it includes information about
this issue.  Does anybody have it?



* Documentation

** History/Bibliography
Some history of Bison and some bibliography would be most welcome.
Are there any Texinfo standards for bibliography?



* Java, Fortran, etc.


** Java

There are a couple of proposed outputs:

- BYACC/J
  which is based on Byacc.
  <http://troi.lincom-asg.com/~rjamison/byacc/>

- Bison Java
  which is based on Bison.
  <http://www.goice.co.jp/member/mo/hack-progs/bison-java.html>