eclipse-qvtd / org.eclipse.qvtd

Eclipse Public License 2.0
0 stars 0 forks source link

[qvtr2qvts] Optimize equality predicate #385

Open eclipse-qvtd-bot opened 2 weeks ago

eclipse-qvtd-bot commented 2 weeks ago

| --- | --- | | Bugzilla Link | 547263 | | Status | NEW | | Importance | P3 normal | | Reported | May 14, 2019 11:25 EDT | | Modified | May 29, 2019 06:52 EDT | | Reporter | Ed Willink |

Description

ATL2QVTr's mapInPattern_qvtr has an =null predicate which could be a simple navigation, but is actually an operation compare and result is true predicate. Simplify.

eclipse-qvtd-bot commented 2 weeks ago

By Ed Willink on May 17, 2019 05:12

RelationAnalysis.synthesizePredicate cherry picks a few special cases such as x=y before falling back on a general expression synthesis for which "=" is an OperationCallExp.

There appears to be scope to attempt to coalesce the left=right nodes generally.

In regards to head analysis in ATL2QVTr mapInPattern has "atlModel.metamodel = null" which currently synthesizes as unconditional/matched giving a contradiction between the optional "metamodel" and the non-optional "=null". This leads to multiple heads and so a bad trace multiplicity.

Workaround, just use getConditionalExpressionSynthesizer(). Not really right. Perhaps "=null" needs special handling. Perhaps "navigation-exp=constant-exp".

eclipse-qvtd-bot commented 2 weeks ago

By Ed Willink on May 17, 2019 06:15

Augmenting the "variable=expression" special case support to handle "navigation-call-exp=expression" is pretty easy.

But what about "operation-call-exp=expression" and ... ?

Worse. What about a three-way predicate expressed as two two-way predicates. The special cases handle the first then get in a mess on the second. The general treatment of no special cases and an EqualsEdge per predicate is not special. A separate later pass can coalesce all the redundant EqualsEdges with a global rather than local view on the challenge.

eclipse-qvtd-bot commented 2 weeks ago

By Ed Willink on May 29, 2019 06:52

(In reply to Ed Willink from comment #2)

Augmenting the "variable=expression" special case support to handle "navigation-call-exp=expression" is pretty easy.

Pushed to master for 2019-06M3.

A separate later pass can coalesce all the redundant EqualsEdges with a global rather than local view on the challenge.

Still to do.