QVT13 — QVTr: Multi-root match

The QVTr AS and CS permit only a single pattern to be matched in the input (and output) domains. QVTc permits multi-matches.

This can be worked around with nested collections as demonstrated by RDomainToMBottomPredicateForEnforcement in RelToCore

remainingUnBoundDomainVars: Set(essentialocl::Variable);
predicatesWithVarBindings:Set(qvtbase::Predicate);

domain relations rdtVarsSeq:Sequence(Set(Element)) {
rdtSet:Set(Element) {
r:Relation{},
rd:RelationDomain{},
te:ObjectTemplateExp {bindsTo = v:Variable {}}
++ _
}
++ _
};

rdtVarsSeq->at(2) = predicatesWithoutVarBindings;
rdtVarsSeq->at(3) = unboundDomainVars;

The above is hard to read and uses nested collections in ways that are claimed to be unsupported. Much simpler to just write:

domain relations
r:Relation{},
rd:RelationDomain{},
te:ObjectTemplateExp {bindsTo = v:Variable {}},
predicatesWithVarBindings:Set(qvtbase::Predicate) {},
remainingUnBoundDomainVars: Set(essentialocl::Variable) {}
;

Suggest in the AS, RelationDomain.pattern changes to RelationDomain.patterns, RelationDomain.rootVariable moves to DomainPattern.rootVariable.

Suggest in the DomainCS CS, "pattern=DomainPatternCS" changes to "patterns+=DomainPatternCS (',' patterns+=DomainPatternCS)*"

As a consequence additional variables may be passed in a RelationCallExp. These can still be in rootVariable order.

QVTr Multi-root match

The QVTr AS and CS permit only a single pattern to be matched in the input (and output) domains. QVTc permits multi-matches.

This can be worked around with nested collections as demonstrated by RDomainToMBottomPredicateForEnforcement in RelToCore

remainingUnBoundDomainVars: Set(essentialocl::Variable);
predicatesWithVarBindings:Set(qvtbase::Predicate);

domain relations rdtVarsSeq:Sequence(Set(Element)) {
rdtSet:Set(Element) {
r:Relation{},
rd:RelationDomain{},
te:ObjectTemplateExp {bindsTo = v:Variable {}}
++ _
}
++ _
};

rdtVarsSeq->at(2) = predicatesWithoutVarBindings;
rdtVarsSeq->at(3) = unboundDomainVars;

The above is hard to read and uses nested collections in ways that are claimed to be unsupported. Much simpler to just write:

domain relations
r:Relation{},
rd:RelationDomain{},
te:ObjectTemplateExp {bindsTo = v:Variable {}},
predicatesWithVarBindings:Set(qvtbase::Predicate) {},
remainingUnBoundDomainVars: Set(essentialocl::Variable) {}
;

Suggest in the AS, RelationDomain.pattern changes to RelationDomain.patterns, RelationDomain.rootVariable moves to DomainPattern.rootVariable.

Suggest in the DomainCS CS, "pattern=DomainPatternCS" changes to "patterns+=DomainPatternCS (',' patterns+=DomainPatternCS)*"

As a consequence additional variables may be passed in a RelationCallExp. These can still be in rootVariable order.

Discussion

This seems to be a completely unnecessary restriction that caused the author of relToCore significant difficulties.

The only downside seems to be a slight increase in complexity of a RelationCallExp. No longer exactly one argument per domain, but linearizing the roots per domain is not exactly hard.

(The spelling in the discussion is that of the Eclipse QVTr prototype. Changing pattern to patterns is not appropriate for QVT1.x where property names tend to be simple-singulars. Perhaps a change to owned-plurals and so ownedPatterns may be appropriate for QVT 2.0.)

Exploiting this in relToCore should wait until an executable version has been debugged.