]> git.saurik.com Git - bison.git/blame - TODO
Update.
[bison.git] / TODO
CommitLineData
416bd7a9
MA
1-*- outline -*-
2
3c146b5e
AD
3* Header guards
4
32f0598d 5From Franc,ois: should we keep the directory part in the CPP guard?
3c146b5e
AD
6
7
c19988b7
AD
8* Yacc.c: CPP Macros
9
10Do some people use YYPURE, YYLSP_NEEDED like we do in the test suite?
11They should not: it is not documented. But if they need to, let's
12find something clean (not like YYLSP_NEEDED...).
13
14
efea6231
AD
15* URGENT: Documenting C++ output
16Write a first documentation for C++ output.
17
bc933ef1 18
88bce5a2
AD
19* Documentation
20Before releasing, make sure the documentation refers to the current
21`output' format.
22
23
d43baf71
AD
24* GLR & C++
25Currently, the GLR parser cannot compile with a C++ compiler.
26
27
2ab9a04f 28* Report
ec3bc396 29
2ab9a04f
AD
30** GLR
31How would Paul like to display the conflicted actions? In particular,
32what when two reductions are possible on a given lookahead, but one is
33part of $default. Should we make the two reductions explicit, or just
34keep $default? See the following point.
d7215705 35
2ab9a04f
AD
36** Disabled Reductions
37See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
38what we want to do.
d7215705 39
2ab9a04f 40** Documentation
bc933ef1
AD
41Extend with error productions. The hard part will probably be finding
42the right rule so that a single state does not exhibit too many yet
43undocumented ``features''. Maybe an empty action ought to be
44presented too. Shall we try to make a single grammar with all these
45features, or should we have several very small grammars?
ec3bc396 46
2ab9a04f
AD
47** --report=conflict-path
48Provide better assistance for understanding the conflicts by providing
49a sample text exhibiting the (LALR) ambiguity. See the paper from
50DeRemer and Penello: they already provide the algorithm.
51
ec3bc396 52
948be909 53* Extensions
2ab9a04f
AD
54
55** yyerror, yysymprint interface
56It should be improved, in particular when using Bison features such as
57locations, and YYPARSE_PARAMS. For the time being, it is recommended
58to #define yyerror and yyprint to steal internal variables...
59
60** Several %unions
6cbfbcc5
AD
61I think this is a pleasant (but useless currently) feature, but in the
62future, I want a means to %include other bits of grammars, and _then_
63it will be important for the various bits to define their needs in
64%union.
76551463 65
5c0a0514
AD
66When implementing multiple-%union support, bare the following in mind:
67
68- when --yacc, this must be flagged as an error. Don't make it fatal
69 though.
70
71- The #line must now appear *inside* the definition of yystype.
72 Something like
73
74 {
75 #line 12 "foo.y"
76 int ival;
77 #line 23 "foo.y"
78 char *sval;
79 }
80
f0e48240
AD
81** %if and the like
82It should be possible to have %if/%else/%endif. The implementation is
83not clear: should it be lexical or syntactic. Vadim Maslow thinks it
84must be in the scanner: we must not parse what is in a switched off
85part of %if. Akim Demaille thinks it should be in the parser, so as
86to avoid falling into another CPP mistake.
87
88** -D, --define-muscle NAME=VALUE
89To define muscles via cli. Or maybe support directly NAME=VALUE?
90
91
fa770c86
AD
92* Unit rules
93Maybe we could expand unit rules, i.e., transform
94
95 exp: arith | bool;
96 arith: exp '+' exp;
97 bool: exp '&' exp;
98
99into
100
101 exp: exp '+' exp | exp '&' exp;
102
103when there are no actions. This can significantly speed up some
d7215705
AD
104grammars. I can't find the papers. In particular the book `LR
105parsing: Theory and Practice' is impossible to find, but according to
106`Parsing Techniques: a Practical Guide', it includes information about
107this issue. Does anybody have it?
fa770c86 108
51dec47b 109
51dec47b 110
2ab9a04f 111* Documentation
51dec47b 112
2ab9a04f
AD
113** History/Bibliography
114Some history of Bison and some bibliography would be most welcome.
115Are there any Texinfo standards for bibliography?
116
117
118
948be909
PE
119* Java, Fortran, etc.
120
948be909 121
f414d77d
AD
122** Java
123
124There are a couple of proposed outputs:
125
126- BYACC/J
127 which is based on Byacc.
128 <http://troi.lincom-asg.com/~rjamison/byacc/>
129
130- Bison Java
131 which is based on Bison.
948be909
PE
132 <http://www.goice.co.jp/member/mo/hack-progs/bison-java.html>
133
f414d77d
AD
134