-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ParserTL reports no reduce/reduce conflicts but bison/byacc/kmyacc repors 35 #15
Comments
See also haskell/happy#260 |
In the end I had to consult the bison source directly, as the docs don't seem to spell this out. From AnnotationList.c, function AnnotationList__computeDominantContribution(): /* R/R conflict, so the reduction with the lowest rule number dominates. and there is no consulting of precedence in this block. I'm therefore assuming this is the valid fix. |
Thank you for replying and fixing it ! To start with some grammars now show reduce/reduce conflicts that were hidden before as resolved (sqlite3.g) but it seems that |
There is also at least one subtlety. Bison will still generate code whether there are shift/reduce or reduce/reduce conflicts or not. This mode of operation is available in parsertl if you pass in the address of a warning string to generator::build(), but if not then any conflicts raise an exception. Be aware that as you are scraping grammars in the wild that it may well be the case that those grammars expect a certain level of conflicts. Note that in the case of a reduce/reduce conflict then bison will favour the earlier rule in the conflict. This is currently unimplemented in parsertl (but would be easy to add). |
I'm looking through the
I'll discuss this in the sqlite forum to see it's author point of view about this, but I do think that the |
This is all good stuff. Just clarifying what the rules are really helps! I'm going to look at the Levine book again for the precedence rules when it comes to associativity, as I'm suspicious my handling is incomplete there for shift/reduce errors. |
I posted this https://sqlite.org/forum/forumpost/9cb2fc0e6e11768c but it seems that I could not articulate properly the issue. |
The point made by Richard Hipp is fair enough. Remember that the reason for supporting precedence in the first place is indeed to allow smaller (and faster) state machines to be constructed from a grammar. When it comes to parsertl, I am happy to do the same as Bison. |
Thinking about it, maybe we could have a flag for lemon mode. That way you could have a directive that you could set and you wouldn't have to worry. |
@BenHanson wrote:
Which fix does "this" refer here to? |
Seemingly bison always treats reduce/reduce as an error regardless of what the precedence of the rules/tokens are. parsertl was previously considering precedence in the reduce/reduce case, which appears to be what the lemon parser generator does also. I'm wondering whether to default to the bison behaviour, but allow the lemon style behaviour with a flag. This reminds me of https://en.cppreference.com/w/cpp/regex/syntax_option_type BTW. |
@BenHanson Thanks for the explanation! However, I find the counterexample given by (Or, I made a mistake in my analysis.) |
While converting this grammar https://github.com/diku-dk/futhark/blob/master/src/Language/Futhark/Parser/Parser.y to be used in https://mingodad.github.io/parsertl-playground/playground/ I found that bison/byacc/kmyacc reports 35 reduce/reduce conflicts but
parsertl
reports then as resolved.On https://mingodad.github.io/parsertl-playground/playground/ select
Futhark parser (partially working)
then clickParse
to see that it parses and produces a parser tree and reports 35 reduce/reduce conflicts as resolved:kmyacc:
bison:
byacc:
Bellow is the grammar that bison/byacc/kmyacc reports 35 reduce/reduce conflicts:
The text was updated successfully, but these errors were encountered: