-
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
Reduce/reduce conflicts with Jison LALR #205
Comments
All tests now pass! The old filter_expr rules failed with a reduce-reduce conflict in the default LALR(1) mode due to a bug in jison: zaach/jison#205 $ jison src/xpath.jison src/xpath.jisonlex ... States with conflicts: State 3 expr -> base_expr . #lookaheads= EOF OR... filter_expr -> base_expr . #lookaheads= ... Aside: the old grammar (with filter_expr uncommented) did work in LR(1) mode, but it takes a LOOOOOONG time to generate which is annoying. $ jison -p lr src/xpath.jison src/xpath.jisonlex
Verified: still a bug. Jison doesn't cope well with epsilon rules which have different FOLLOW sets: these are merged into a single state while they shouldn't. |
…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.
… optimizations too: when there's no match, i.e. a parse error, then the parser still invokes `parseError()` like in the old days and has it throw an exception if you don't override it, but you can also make it return `false` to turn the parser into a true *matcher*, returning `true` or `false` whether the input parses correctly or not! See examples/issue-205-2.jison.
… optimizations too: when there's no match, i.e. a parse error, then the parser still invokes `parseError()` like in the old days and has it throw an exception if you don't override it, but you can also make it return `false` to turn the parser into a true *matcher*, returning `true` or `false` whether the input parses correctly or not! See examples/issue-205-2.jison.
Since Jison uses "LALR(1) by SLR(1)" algorithm, it seems incorrectly merges the lookaheads in the extended grammar, based only on the same final set. This should either be by compressing from CLR(1) with full lookahead sets, or consider correct LHS of a rule. If this is still the issue for Jison, one can also use the alternative, the Syntax tool, which doesn't have this issue (including for epsilon rules), and has the same grammar format. |
… from BNFC/bnfc#132. Related to zaach#205: reduce/reduce conflict in jison, not in bison...
Working on a parser for the Modelica language, Jison eventually required the
-p lr
option to avoid reduce/reduce conflicts. The same parser rules work with Bison and PLY though.Here is a simple example that fails with Jison, while running well with Bison (2.4.1 and 2.5):
The error message is:
The problems with
-p lr
are the long runtime of Jison (about 2-3 minutes onmoparser.jison
) and the large size of the resultingmoparser.js
.The text was updated successfully, but these errors were encountered: