Re: Why is this a shift/reduce conflict?

[Akim Demaille]

Le 5 juin 2013 à 00:06, Adam Smalin <address@hidden> a écrit :

> During my test to get  << a difference precedence then < I suspect it is
> impossible because after expr < expr [<] it has no idea if it will be a <<
> expr or an < expression thus I can't tell it to have a different precedence
> between < and < <.
> 
> Because I can't I wrote this test grammar. When I execute `a<b< <cd<e` I
> get << < < as I wanted. The issue is 2 shift reduce conflicts. I can't
> understand it. It does exactly what I want (<< before <). Its has
> %glr-parser at the top. Why isn't it ok shifting and reducing when it can't
> complete the longer rule (mainElement3). I'm just confused all over I don't
> see the conflict. How would I rewrite this to not have the conflict?

If I understand correctly your question, then you definitely need to
read again the documentation of GLR.  The whole point of GLR is
*keeping* (some) conflicts, deferring their resolution at parse-time,
instead of bison-time.  Actually, you may even _not_ resolve the
conflicts at run-time if you have an ambiguous grammar and if you
want to get all the possible parse-trees.

Consider this stupid grammar:

exp:
  padding 'a'
| padding 'b'

padding:
  %empty
| padding 'x'

It is clearly non-ambiguous, yet not LR.  Bison will no doubt
see conflicts, but you _want_ the conflicts to be kept so that
the parser explore both possible parses until it finally finds
the 'a' or the 'b'.  "Solving" the conflict would doom your parser
to accept only one of the two possibilities.