1 |
-*- outline -*- |
-*- outline -*- |
2 |
|
|
3 |
|
* documentation |
4 |
|
Explain $axiom (and maybe change its name: BTYacc names it goal). |
5 |
|
Complete the glossary (item, axiom, ?). |
6 |
|
|
7 |
|
* report documentation |
8 |
|
Extend with error. The hard part will probably be finding the right |
9 |
|
rule so that a single state does not exhibit to many yet undocumented |
10 |
|
``features''. Maybe an empty action ought to be presented too. Shall |
11 |
|
we try to make a single grammar with all these features, or should we |
12 |
|
have several very small grammars? |
13 |
|
|
14 |
|
* documentation |
15 |
|
Some history of Bison and some bibliography would be most welcome. |
16 |
|
Are there any Texinfo standards for bibliography? |
17 |
|
|
18 |
* Several %unions |
* Several %unions |
19 |
I think this is a pleasant (but useless currently) feature, but in the |
I think this is a pleasant (but useless currently) feature, but in the |
20 |
future, I want a means to %include other bits of grammars, and _then_ |
future, I want a means to %include other bits of grammars, and _then_ |
36 |
char *sval; |
char *sval; |
37 |
} |
} |
38 |
|
|
39 |
* Experimental report features |
* --report=conflict-path |
40 |
Decide whether they should be enabled, or optional. For instance, on: |
Provide better assistance for understanding the conflicts by providing |
41 |
|
a sample text exhibiting the (LALR) ambiguity. |
|
input: |
|
|
exp |
|
|
| input exp |
|
|
; |
|
|
|
|
|
exp: |
|
|
token1 "1" |
|
|
| token2 "2" |
|
|
| token3 "3" |
|
|
; |
|
|
|
|
|
token1: token; |
|
|
token2: token; |
|
|
token3: token; |
|
|
|
|
|
the traditional Bison reports: |
|
|
|
|
|
state 0 |
|
|
|
|
|
$axiom -> . input $ (rule 0) |
|
|
|
|
|
token shift, and go to state 1 |
|
|
|
|
|
input go to state 2 |
|
|
exp go to state 3 |
|
|
token1 go to state 4 |
|
|
token2 go to state 5 |
|
|
token3 go to state 6 |
|
|
|
|
|
state 1 |
|
|
|
|
|
token1 -> token . (rule 6) |
|
|
token2 -> token . (rule 7) |
|
|
token3 -> token . (rule 8) |
|
|
|
|
|
"2" reduce using rule 7 (token2) |
|
|
"3" reduce using rule 8 (token3) |
|
|
$default reduce using rule 6 (token1) |
|
|
|
|
|
while with --trace, i.e., when enabling both the display of non-core |
|
|
item sets and the display of lookaheads, Bison now displays: |
|
|
|
|
|
state 0 |
|
|
|
|
|
$axiom -> . input $ (rule 0) |
|
|
input -> . exp (rule 1) |
|
|
input -> . input exp (rule 2) |
|
|
exp -> . token1 "1" (rule 3) |
|
|
exp -> . token2 "2" (rule 4) |
|
|
exp -> . token3 "3" (rule 5) |
|
|
token1 -> . token (rule 6) |
|
|
token2 -> . token (rule 7) |
|
|
token3 -> . token (rule 8) |
|
|
|
|
|
token shift, and go to state 1 |
|
|
|
|
|
input go to state 2 |
|
|
exp go to state 3 |
|
|
token1 go to state 4 |
|
|
token2 go to state 5 |
|
|
token3 go to state 6 |
|
|
|
|
|
state 1 |
|
|
|
|
|
token1 -> token . ["1"] (rule 6) |
|
|
token2 -> token . ["2"] (rule 7) |
|
|
token3 -> token . ["3"] (rule 8) |
|
|
|
|
|
"2" reduce using rule 7 (token2) |
|
|
"3" reduce using rule 8 (token3) |
|
|
$default reduce using rule 6 (token1) |
|
|
|
|
|
so decide whether this should be an option, or always enabled. I'm in |
|
|
favor of making it the default, but maybe we should tune the output to |
|
|
distinguish core item sets from non core: |
|
|
|
|
|
state 0 |
|
|
Core: |
|
|
$axiom -> . input $ (rule 0) |
|
|
|
|
|
Derived: |
|
|
input -> . exp (rule 1) |
|
|
input -> . input exp (rule 2) |
|
|
exp -> . token1 "1" (rule 3) |
|
|
exp -> . token2 "2" (rule 4) |
|
|
exp -> . token3 "3" (rule 5) |
|
|
token1 -> . token (rule 6) |
|
|
token2 -> . token (rule 7) |
|
|
token3 -> . token (rule 8) |
|
|
|
|
|
token shift, and go to state 1 |
|
|
|
|
|
input go to state 2 |
|
|
exp go to state 3 |
|
|
token1 go to state 4 |
|
|
token2 go to state 5 |
|
|
token3 go to state 6 |
|
|
|
|
|
|
|
|
> So, it seems clear that it has to be an additional option :) |
|
|
|
|
|
Paul: |
|
|
|
|
|
There will be further such options in the future, so I'd make |
|
|
them all operands of the --report option. E.g., you could do |
|
|
something like this: |
|
42 |
|
|
43 |
--report=state --report=lookahead --report=itemset |
* report |
44 |
--report=conflict-path |
Solved conflicts should not be reported in the beginning of the file. |
45 |
|
Rather they should be reported within each state description. Also, |
46 |
|
now that the symbol providing the precedence of a rule is kept, it is |
47 |
|
possible to explain why a conflict was solved this way. E.g., instead |
48 |
|
of |
49 |
|
|
50 |
where "--verbose" is equivalent to "--report=state", and where |
Conflict in state 8 between rule 2 and token '+' resolved as reduce. |
|
"--report=conflict-path" reports each path to a conflict |
|
|
state. |
|
51 |
|
|
52 |
(As a minor point, I prefer avoiding plurals in option names. |
we can (in state 8) report something like |
|
It's partly for brevity, and partly to avoid wearing out the |
|
|
's' keys in our keyboards. :-) |
|
53 |
|
|
54 |
To implement this, see in the Fileutils the latest versions of |
Conflict between rule 2 and token '+' resolved as reduce |
55 |
argmatch and so forth. |
because '*' < '+'. |
56 |
|
|
57 |
|
or something like that. |
58 |
|
|
59 |
* Coding system independence |
* Coding system independence |
60 |
Paul notes: |
Paul notes: |