git.saurik.com Git - bison.git/blame_incremental

... / ...

Commit	Line	Data
	1	-- outline --
	2
	3	* Header guards
	4
	5	From Franc,ois: should we keep the directory part in the CPP guard?
	6
	7
	8	* URGENT: Documenting C++ output
	9	Write a first documentation for C++ output.
	10
	11
	12	* Documentation
	13	Before releasing, make sure the documentation refers to the current
	14	`output' format.
	15
	16
	17	* Error messages
	18	Some are really funky. For instance
	19
	20	type clash (`%s' `%s') on default action
	21
	22	is really weird. Revisit them all.
	23
	24
	25	* read_pipe.c
	26	This is not portable to DOS for instance. Implement a more portable
	27	scheme. Sources of inspiration include GNU diff, and Free Recode.
	28
	29
	30	* value_components_used
	31	Was defined but not used: where was it coming from? It can't be to
	32	check if %union is used, since the user is free to $<foo>n on her
	33	union, doesn't she?
	34
	35
	36	* GLR & C++
	37	Currently, the GLR parser cannot compile with a C++ compiler.
	38
	39
	40	* Report
	41
	42	** GLR
	43	How would Paul like to display the conflicted actions? In particular,
	44	what when two reductions are possible on a given lookahead, but one is
	45	part of $default. Should we make the two reductions explicit, or just
	46	keep $default? See the following point.
	47
	48	** Disabled Reductions
	49	See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
	50	what we want to do.
	51
	52	** Documentation
	53	Extend with error productions. The hard part will probably be finding
	54	the right rule so that a single state does not exhibit too many yet
	55	undocumented ``features''. Maybe an empty action ought to be
	56	presented too. Shall we try to make a single grammar with all these
	57	features, or should we have several very small grammars?
	58
	59	** --report=conflict-path
	60	Provide better assistance for understanding the conflicts by providing
	61	a sample text exhibiting the (LALR) ambiguity. See the paper from
	62	DeRemer and Penello: they already provide the algorithm.
	63
	64
	65	* Extensions
	66
	67	** yyerror, yysymprint interface
	68	It should be improved, in particular when using Bison features such as
	69	locations, and YYPARSE_PARAMS. For the time being, it is recommended
	70	to #define yyerror and yyprint to steal internal variables...
	71
	72	** Several %unions
	73	I think this is a pleasant (but useless currently) feature, but in the
	74	future, I want a means to %include other bits of grammars, and _then_
	75	it will be important for the various bits to define their needs in
	76	%union.
	77
	78	When implementing multiple-%union support, bare the following in mind:
	79
	80	- when --yacc, this must be flagged as an error. Don't make it fatal
	81	though.
	82
	83	- The #line must now appear inside the definition of yystype.
	84	Something like
	85
	86	{
	87	#line 12 "foo.y"
	88	int ival;
	89	#line 23 "foo.y"
	90	char *sval;
	91	}
	92
	93	* Unit rules
	94	Maybe we could expand unit rules, i.e., transform
	95
	96	exp: arith \| bool;
	97	arith: exp '+' exp;
	98	bool: exp '&' exp;
	99
	100	into
	101
	102	exp: exp '+' exp \| exp '&' exp;
	103
	104	when there are no actions. This can significantly speed up some
	105	grammars. I can't find the papers. In particular the book `LR
	106	parsing: Theory and Practice' is impossible to find, but according to
	107	`Parsing Techniques: a Practical Guide', it includes information about
	108	this issue. Does anybody have it?
	109
	110
	111
	112	* Documentation
	113
	114	** History/Bibliography
	115	Some history of Bison and some bibliography would be most welcome.
	116	Are there any Texinfo standards for bibliography?
	117
	118
	119
	120	* Java, Fortran, etc.
	121
	122
	123	** Java
	124
	125	There are a couple of proposed outputs:
	126
	127	- BYACC/J
	128	which is based on Byacc.
	129	<http://troi.lincom-asg.com/~rjamison/byacc/>
	130
	131	- Bison Java
	132	which is based on Bison.
	133	<http://www.goice.co.jp/member/mo/hack-progs/bison-java.html>
	134
	135