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