Regen.

[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 refers to the current
`output' format.


* Error messages
Some are really funky.  For instance

	type clash (`%s' `%s') on default action

is really weird.  Revisit them all.


* 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

** yyerror, 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...

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