Ambiguous Alternatives

[sveri]

I have trouble getting alternatives to work. I have seen that article: https://chevrotain.io/docs/guide/resolving_grammar_errors.html#AMBIGUOUS_ALTERNATIVES and it absolutely makes sense.
However, there is one alternative missing.

Taking the example from the page:

fiveTokensLookahead:
  "A" "B" "C" "D" "1" |
  "A" "B" "C" "D" "2"

I have another alternative, the one with an "empty" end:

fiveTokensLookahead:
  "A" "B" "C" "D" "1" |
  "A" "B" "C" "D" "2" |
  "A" "B" "C" "D"

How would I resolve this using chevrotain?

[bd82]

Does Chevrotain complain about this during parser initialization or only fails at runtime?

Naively I would refactor this and extract the common prefix

fiveTokensLookahead:
  "A" "B" "C" "D" ("1" | "2")?

If for whatever reason that is not possible you could consider using GATES to distinguish between the alternatives

• https://chevrotain.io/docs/features/gates.html

In theory you could write your own lookahead logic inside the GATEs, going as far as using backtracking
But I would recommend to avoid too complex grammars if possible.

• https://chevrotain.io/docs/features/backtracking.html

[sveri]

I would like to implement your refactoring example, but don't know how to express the third case ("A" "B" "C" "D") without "1" or "2"?.
Something like:

$.CONSUME(ABCD);
$.OR([
    { ALT: () => element += $.SUBRULE($.1)},
    { ALT: () => element += $.SUBRULE($.2)},
]);

but how about the third case? What if neither "1" nor "2" exists in the input string?

[sveri]

It seems like something like this works:

$.MANY_SEP({
            SEP: T.Comma, DEF: () => {
                let element = $.SUBRULE($.argumentsWithSimpleType);
                $.OPTION(() => { 
                    $.OR([
                        { ALT: () => element += $.SUBRULE($.bracketWithSimpleTypeApplication)},
                        { ALT: () => element += $.SUBRULE($.bracketWithArgumentTypeApplication)},
                        // { ALT: () => element = $.SUBRULE($.bracketWithArgumentTypeApplicationAndType)},
                    ]);
                });
                argumentsWithType.push(element);
            }
        });

Is that good style?

[bd82]

Is that good style?

From a grammar's ambiguity level yes.
From a coding maintenance and/or readability level you may want to extract some of the code blocks
to helper rules with meaningful names, and have multiple smaller rules, e.g:

chevrotain/examples/grammars/tinyc/tinyc.js

Lines 57 to 82 in efbc5da

	$.RULE("program", () => {
	$.MANY(() => {
	$.SUBRULE($.statement)
	})
	})
	$.RULE("statement", () => {
	$.OR([
	{ ALT: () => $.SUBRULE($.ifStatement) },
	{ ALT: () => $.SUBRULE($.whileStatement) },
	{ ALT: () => $.SUBRULE($.doStatement) },
	{ ALT: () => $.SUBRULE($.blockStatement) },
	{ ALT: () => $.SUBRULE($.expressionStatement) },
	{ ALT: () => $.SUBRULE($.emptyStatement) }
	])
	})
	$.RULE("ifStatement", () => {
	$.CONSUME(If)
	$.SUBRULE($.paren_expr)
	$.SUBRULE($.statement)
	$.OPTION(() => {
	$.CONSUME(Else)
	$.SUBRULE2($.statement)
	})
	})

From this snippet it is very clear:

• A program is made up of a sequence of statements
• A statement may be one of ifStatement , whileStatement, ...