-
Notifications
You must be signed in to change notification settings - Fork 452
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
grammar conflict in LALR, but works in SLR and LR(1). Bison also works. #342
Comments
Yes, it is. This is the same problem as #205. Looking into it.
On Feb 1, 2017 9:50 PM, "Chizhong Jin" <notifications@github.com> wrote:
Hi friend,
Thank you for your awesome project.
I wrote a jison file, but it not works.
After all, I got following snippet to reproduce the problem.
%token ID
%%
stmt
: type ID ';'
| expr ';'
;
type
: ID
;
expr
: ID
;
This snippet works fine in SLR and LR.
Also works fine in BISON (both LALR, IELR, LR)
I'm a new of yacc, I can not found out where the problem is.
But due to BISON and SLR work fine.
I think maybe this is an issue.
Can you help me?
Thank you
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#342>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAYkHjU4NY1fDfHqvnkmzv82_Y32dblwks5rYPAqgaJpZM4L0XrO>
.
|
…d by a non-empty rule instead to check if this is epsilon-rule related or a fundamental LALR issue (which got reported as zaach#342 while I was looking at this one)
…ct in LALR mode, we tag the relevant *production* (it turns out tagging the *state* as well *corrupts* the parse table; something to look into later when my head is clearer as I don't see why, right now) and rerun the state machine generation process, where we make sure the UNION operator for the conflicting production WILL NOT merge it with other productions which may have the same FOLLOW set as this conflicting rule. As such, we fundamentally are 'locally' breaking LALR principles and turning them into LR-style behaviour for the conflict zone alone. (Side Note To Self: I recall having seen a short 1-column letter to the ACM (published by the ACM) from a few decades ago which mentioned that the algorithm used here is flawed, but cannot track it down in my library, darn it! So no reference to check if there's more amiss then this (zaach#342 + zaach#205). Also would like to check myself if this is IELR 're-invented', either in part or whole? Now I am curious... (Never got more than the abstract for that one and bison code isn't exactly obvious to me either.) Doubly dang-it! |:-( )
…number of **unresolved conflicts** as part of the `-I` output at the end of a jison run and clean up the corresponding conflict counting while we re-run the state machine generation in jison when such conflicts have been found... (more work for zaach#205 + zaach#342) Also augment the test set fed into the zaach#342 test grammar to make sure it behaves exactly as desired.
Provisionally fixed in the https://github.com/GerHobbelt/jison fork in the next build. (Have to nail #343 before this build/release will be available!) See commits:
|
:) Thank you very much |
Hi friend,
Thank you for your awesome project.
I wrote a jison file, but it not works.
After all, I got following snippet to reproduce the problem.
This snippet works fine in SLR and LR.
Also works fine in
BISON
(both LALR, IELR, LR)I'm a new of yacc, I can not found out where the problem is.
But due to
BISON
andSLR
work fine.I think maybe this is an issue.
Can you help me?
Thank you
The text was updated successfully, but these errors were encountered: