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...).


* readpipe

It should be replaced to avoid tmp files and to improve portability.
Also, as it is it does not call error () when execve fails, and
therefore, running M4='m4 --version' bison will silently fail instead
of:

	bison: cannot run m4 --version: No such file or directory

BTW: I would really like to be able to pass arguments to m4...


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


* read_pipe.c
This is not portable to DOS for instance.  Implement a more portable
scheme.  Sources of inspiration include GNU diff, and Free Recode.


* value_components_used
Was defined but not used: where was it coming from?  It can't be to
check if %union is used, since the user is free to $<foo>n on her
union, doesn't she?


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

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