Closed PaulChernoch-Shell closed 3 years ago
The above issue seems to spring from this parser grammar rule:
FilterExpression
= head:LeftExph __ "[" __ tail:Expression __ "]"
{
log(`FilterExpression (${text()})`);
return new ast.FilterExpressionNode(head,tail,location(), text(), rule());
}
In the specification for DMN 1.2, p113 of section 2.3.1.2, the rule is:
52. filter expression = expression , "[" , expression , "]" ;
Use of head:LeftExph restricts the LHS to TxtExpi, which is Name, Literal or SimplePositiveUnaryTest.
I suspect there is a recursion problem in the grammar that this rule hopes to avoid, but it eliminates valid expressions from being parsed. I will see if I can tweak the grammar on my machine to fix it.
I have found a fix. In the grammar, make these changes:
Expression
= expr:BoxedExpression !(__ ("[" / "."))
{
return expr;
}
/ TextualExpression
FilterExpression
= head:LeftExph __ "[" __ tail:Expression __ "]"
{
log(`FilterExpression (${text()})`);
return new ast.FilterExpressionNode(head,tail,location(), text(), rule());
}
/ head:BoxedExpression __ "[" __ tail:Expression __ "]"
{
log(`FilterExpression (${text()})`);
return new ast.FilterExpressionNode(head,tail,location(), text(), rule());
}
PathExpression
= head:LeftExpg tail: (__ "." __ Expression)+
{
log(`PathExpression (${text()})`);
return new ast.PathExpressionNode(buildList(head,tail,3),location(), text(), rule());
}
/ head:BoxedExpression tail: (__ "." __ Expression)+
{
log(`PathExpression (${text()})`);
return new ast.PathExpressionNode(buildList(head,tail,3),location(), text(), rule());
}
It would probably be a good idea to add some regression tests. I verified that this executes correctly for some simple cases.
Hi. I have made the changes. It doesn't seem to disrupt the other tests. It will be impossible for me to discover these issues, much less come out with a fix such as this. So thanks again.
The changes will come into the repo in the following week.
If a list is part of the context, you may use a filter expression on it. However, if the list is a list literal, attempting to extract data from it using a filter expression produces a parse error. A corresponding problem exists if you try to access a property of a context literal using the dot operator.
I have verified that the failing expression parses and properly exedcutes against a Feel 1.3 implementation. I assume but am not sure that 1.1 was supposed to support this case.
SUCCESSFUL PARSE:
Parse tree for rule 'employees[3]' is:
UNSUCCESSFUL PARSE:
Parse tree for rule '["Sally", "Harry", "Dilbert", "Dogbert"] [3]' is: