yurloc commented on PR #5899: URL: https://github.com/apache/incubator-kie-drools/pull/5899#issuecomment-2098194306
Quick ideas (feel free to ignore if it's too cryptic but I need to put it down) - I can see 3 options: 1. Eat the `||` token temporarily to make the operator predicate visible and kill the unwanted option. Then puke it (go 1 step backward in the token stream), and exit `relationalExpression` as expected. 2. Do nothing. Keep the predicate invisible during alternative exploration, then let it fail with no viable alternative (that's what currently happens) and then use custom error strategy to somehow recover and exit `relationalExpression` as expected. 3. Somehow redesign the rules. Find another way to kill the alternative without using a sempred (disallow `parExpression` after `operator` if we're inside `relationExpression`???) resulting in a compromise that keeps general scenario working, makes this specific usecase work but disables some edge-case expressions. Use a nongreedy subrule? Guard the `|| orRestriction` alternative with a new sempred (`helper.isPluggableEvaluator()`) that looks at the next-next token? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
