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

Reduce/reduce conflicts with Jison LALR #205

Open
rfranke opened this issue Jan 14, 2014 · 2 comments
Open

Reduce/reduce conflicts with Jison LALR #205

rfranke opened this issue Jan 14, 2014 · 2 comments

Comments

@rfranke
Copy link

rfranke commented Jan 14, 2014

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):

%token PREFIX1 PREFIX2 SUFFIX1 SUFFIX2

%%

start:
           opt_prefix1 SUFFIX1
        |  opt_prefix2 SUFFIX2
        ;

opt_prefix1:
          /* empty */
        | PREFIX1
        ;

opt_prefix2:
          /* empty */
        | PREFIX2
        ;

%%

The error message is:

Conflict in grammar: multiple actions possible when lookahead token is SUFFIX1 in state 0
- reduce by rule: opt_prefix2 ->
- reduce by rule: opt_prefix1 ->
Conflict in grammar: multiple actions possible when lookahead token is SUFFIX2 in state 0
- reduce by rule: opt_prefix2 ->
- reduce by rule: opt_prefix1 ->

The problems with -p lr are the long runtime of Jison (about 2-3 minutes on moparser.jison) and the large size of the resulting moparser.js.

millerdev added a commit to dimagi/js-xpath that referenced this issue Jul 9, 2015
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
@GerHobbelt
Copy link
Contributor

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.

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

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.

GerHobbelt added a commit to GerHobbelt/jison that referenced this issue Aug 26, 2018
… from BNFC/bnfc#132. Related to zaach#205: reduce/reduce conflict in jison, not in bison...
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

3 participants