Pattern match syntax alternative in function signature - rascal

Question

I have a rascal syntax containing various type of change operators :
syntax ChangeOperator
= entityOperator: EntityOperation op
| attributeOperator : AttributesOperations op
| relationOperator: RelationOperations op
| databaseOperator: DatabaseOperations op
;
And I try to execute different action depending on the type of the change operator (EntityOperation, AttributeOperation, ...). I loop through my change operator like this :
for ( ChangeOperator op <- operators){
for(EvoQuery evo <- evoQueries){
transform(evo, op);
}
};
And I defined various transform methods :
EvoQuery transform(EvoQuery q, EntityOperation op){ ... }
EvoQuery transform(EvoQuery q, AttributesOperations op) {...}
default EvoQuery transform(EvoQuery q, _) = q;
Unfortunately, the only version of 'transform' that is called is the default one.
How can I adapt the loop or the signature in order to make them match depending on the kind of the alternative ?

Answer 1

It seems that there is a type mismatch between the pattern in the formal parameter and the actual argument in the loop (which is now a ChangeOperator, not some Operation). Changing the call to the transform function to transform(evo, op.op), will likely give the intended result.
Furthermore, the two for loops can be combined into a single one as follows:
for (ChangeOperator op <- operators, EvoQuery evo <- evoQueries) {
transform(evo, op);
};

Answer 2

The first two alternatives of transform fail because the type of the parameter op in the body of the for-loop is neither an EntityOperation nor an AttributusOperations: it's ChangeOperator. In other words: concrete syntax types are not sub-types even if the rule that defines them is only a "chain rule".
To match one level deep in a tree, you can use either concrete matching or abstract matching, like so:
In concrete syntax, we parse a ChangeOperator snippet with a single hole in it, and use that pattern to match against the parse tree that you give as second parameter:
EvoQuery transform(EvoQuery q, (ChangeOperator) `<EntityOperation op>`) { ... }
EvoQuery transform(EvoQuery q, (ChangeOperator) `<AttributesOperations op>`) {...}
In abstract notation, we can use the name label of each alternative syntax rule of ChangeOperator to match the alternative instead. So in this example we use abstract notation to match against concrete parse trees:
EvoQuery transform(EvoQuery q, entityOperator(EntityOperation op)) { ... }
EvoQuery transform(EvoQuery q, attributeOperator(AttributesOperations op)) {...}
PS: there is a bug in this definition:
syntax ChangeOperator
= entityOperator: EntityOperation op
| attributeOperator : AttributesOperations op
| relationOperator: RelationOperations op
| databaseOperator: DatabaseOperations op
;
each op label should be different because they yield different types:
syntax ChangeOperator
= entityOperator: EntityOperation eop
| attributeOperator : AttributesOperations aop
| relationOperator: RelationOperations rop
| databaseOperator: DatabaseOperations dop
;