Skip to content
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

Open
pjincz opened this issue Feb 1, 2017 · 3 comments
Open

Comments

@pjincz
Copy link

pjincz commented Feb 1, 2017

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

@GerHobbelt
Copy link
Contributor

GerHobbelt commented Feb 2, 2017 via email

GerHobbelt added a commit to GerHobbelt/jison that referenced this issue Feb 3, 2017
…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)
GerHobbelt added a commit to GerHobbelt/jison that referenced this issue Feb 3, 2017
GerHobbelt added a commit to GerHobbelt/jison that referenced this issue Feb 3, 2017
…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!   |:-(   )
GerHobbelt added a commit to GerHobbelt/jison that referenced this issue Feb 3, 2017
…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.
@GerHobbelt
Copy link
Contributor

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:

@pjincz
Copy link
Author

pjincz commented Feb 6, 2017

:) Thank you very much

GerHobbelt added a commit to GerHobbelt/jison that referenced this issue Feb 20, 2017
GerHobbelt added a commit to GerHobbelt/jison that referenced this issue Feb 20, 2017
GerHobbelt added a commit to GerHobbelt/jison that referenced this issue Feb 20, 2017
…aach#289, zaach#342 and zaach#344 (the latter is still failing at run-time) -- adjusted the zaach#289 grammar to match the test code, while the problem remains the same. These grammars are all dependent on the new conflict resolution logic available in this jison fork.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants