bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TODO update


From: Paul Hilfinger
Subject: Re: TODO update
Date: Wed, 24 Jul 2002 18:51:49 -0700

 > I think we are still not understanding each other.  output is
 > generated *before* the computation of actrow and the like.  It does
 > *not* use the same computation of `default' as the ``real'' automaton
 > does.

Ah, I see.  Well, fine: for whatever reason, the report (-v) output
is, as far as I can see, almost OK.  Perhaps your concern is caused by:

 > I'm referring to the fact that, unless I'm mistaken, there is no such
 > thing as a $default in GLR, so first of all, $default has nothing to
 > do here.

On the contrary, $default IS still used in GLR parsers---just never
for conflicted entries.  

 > | I'm not sure why you say so.  The one potentially confusing thing is
 > | that the first $ rule (since there is no S/R conflict) is not
 > | bracketed, even though it is, in fact, treated identically to the 
 > | other $ rule (which is bracketed).   This is an artifact of bison's
 > | reporting of the OTHER sense of 'default' reduction---i.e., the
 > | reduction taken by default when there is a R/R conflict for the
 > | ordinary LALR(1) parser.
 > 
 > I disaagree on the reading.  What Bison wrote above is
 > 
 >         There are several possible actions on $: r1 and r2.
 >         r2 is disabled.
 >         There are several on +: s4, r1, r2.
 >         r1 and r2 are disabled.
 > 
 > *That's* what ``means'' Bison. `[]' means `possible according to the
 > grammar, but no executed at all because of conflicts', not `because of
 > $default'.

Argh; this terminology is confusing.  When I said "the OTHER sense of
'default'" I meant exactly what you just wrote---the selection of the
first of two conflicting rules in the case of R/R conflicts and the
disabling of the rest---as opposed to "$default"---the rule that is
executed when there is no entry in the action table for a given 
State x Token pair.  In other words, bracketed entries don't really
make sense for GLR parsing, just as you say next:

 > In the present case, it ought to be
 > 
 > state 5
 > 
 >     1 exp: exp . '+' exp  [$, '+']
 >     1    | exp '+' exp .  [$, '+']
 >     2    | exp . '+' exp  [$, '+']
 >     2    | exp '+' exp .  [$, '+']
 > 
 >     '+'  shift, and go to state 4
 > 
 >     $         reduce using rule 1 (exp)
 >     $         reduce using rule 2 (exp)
 >     '+'       reduce using rule 1 (exp)
 >     '+'       reduce using rule 2 (exp)
 >     $default  reduce using rule 1 (exp)

Correct.

 > and I was, in addition, questioning the presence of this $default
 > guy.  Should it be:
 > 
 > state 5
 > 
 >     1 exp: exp . '+' exp  [$, '+']
 >     1    | exp '+' exp .  [$, '+']
 >     2    | exp . '+' exp  [$, '+']
 >     2    | exp '+' exp .  [$, '+']
 > 
 >     '+'  shift, and go to state 4
 > 
 >     $         reduce using rule 1 (exp)
 >     $         reduce using rule 2 (exp)
 >     '+'       reduce using rule 1 (exp)
 >     '+'       reduce using rule 2 (exp)
 > 

No.  Your first one is right.  $default reductions are still used by
the GLR parser (when there is no conflict for a particular table entry).

Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]