Re: extra lookahead sets in report

[Joel E. Denny]

On Thu, 18 Oct 2007, Akim Demaille wrote:

> >>> "JED" == Joel E Denny <address@hidden> writes:
> 
>  > I committed this.  Is it significant enough for NEWS?
> 
> I would say so.

Ok, I'll add an entry soon.

>  > +# Within a single state, Bison used to print a reduction's lookahead set 
> next
>  > +# to all items of the associated rule.  Instead, it should only print it 
> next
>  > +# to the item that is of the associated rule and whose dot is at the end 
> of the
>  > +# RHS.  Printing it next to items whose dot is not at the end of the RHS 
> is
>  > +# sometimes redundant and, as in this test case, is sometimes incorrect.
> 
> I don't remember the details, but are you saying that the lookahead
> set is not computed for each item, but rather for a single rule?

Yes.  Bison uses DeRemer and Pennello's algorithm for computing lookahead 
sets.

> I found it quite convenient to have all the lookahead sets when trying
> to understand some conflicts but following the lookaheads starting
> from $start (more LR(1) than LALR(1), but still useful to understand
> what's going on).

I agree it would be helpful.

> Even if the result is incorrect (excuse my Bison's French ;)
> 
>   état 1
>   
>       2 start: 'a' . a 'a'
>       3 a: . 'a'  [$end]

The above lookahead set is incorrect.  It should be:

        3 a: . 'a'  ['a']

The 'a' comes from the previous item.  I should add a comment to the test 
case to make this clearer.

>       3  | 'a' .  [$end]
>   
>       'a'  décalage et aller à l'état 4
>   
>       $défaut  réduction par utilisation de la règle 3 (a)
>   
>       a  aller à l'état 5
> 
> it does faithfully reflect the automaton, right?

I think the actions are fine, and thus the parser tables in C/C++/Java are 
fine.  It's just that the report sometimes misused the computed lookahead 
sets.

Did I answer your question?