[qvtr] when/where, multi-realize/assign semantics

[eclipse-qvtd-bot]

| --- | --- | | Bugzilla Link | 515237 | | Status | NEW | | Importance | P3 normal | | Reported | Apr 13, 2017 05:04 EDT | | Modified | Apr 14, 2017 04:02 EDT | | Blocks | 515236 | | See also | 512738, 509281 | | Reporter | Ed Willink |

Description

Problem. In a (deep) enforced pattern, which property template items are predicates and which are realized? Why shouldn't an enforced pattern have a 3-term predicated search followed by a 3-term realize?

Translation to QVTc must annotate every "realize" and use ":=" rather than "=" for property assignments.

Currently the code is pragmatic. when's realize, but where's are vague.

? change the language: "checkonly" prefix for predicate pattern properties. Ugh! awfully reminiscent of a Prolog cut.

? distinguish good/bad exposition style and force user to program clearly.

? QVTr is abstract final truth. The tooling must figure it out.

But consider two enforced patterns that contribute each side of a diamond pattern: A-B1-C1, A-B2-C2. The distant types C1,C2 may be distinct but conformant depending on the path. The first to execute may create the 'wrong' type inhibiting the unification of the diamond. Such unification only really works if C1/C2 is created by a unique mapping. QVTr Keys might be another solution, but they seem to have all the same problems.

In the QVTc it would seem that we must have unique mappings for ambiguous predicate/realizes. So in the short term we require the programmer to use good style that makes these easy to convert from QVTr to QVTc. In the long term we should recognize the hazard and extract the mappings automatically.

[eclipse-qvtd-bot]

By Ed Willink on Apr 13, 2017 14:15

(In reply to Ed Willink from comment #0)

Currently the code is pragmatic. when's realize, but where's are vague.

Perhaps not.

A regular relation (which may be whened) enforces (realizes) its output. It is therefore an output domain bottom pattern realized variable.

A non-top relation (which may be whered) uses (predicates) the passed output. It is therefore an output domain guard pattern variable.

[eclipse-qvtd-bot]

By Ed Willink on Apr 14, 2017 04:02

In principle all when's are predicates, so obviously must be satisfied (execute) before any pattern is enforced. when input domains must obviously be input. when outputs are sensibly outputs, but could also be checked for consistency and so outputs with a compare.

Plausibly, plumbing of when arguments could benefit from shared variables, and so some of the relation variables could be executed as part of the when logic. See Bug 512738.

If the 'when' involves an output pattern re-search, the shared target should be created by a unifying relation. WFR requires. See Bug 509281.

---

All where's are corrolaries; no pattern enforcement can occur after the where execution to exploit the where's 'outputs'. Therefore all where input and output domains are 'inputs' as far as the caller is concerned.

If a program requires to exploit the 'where' then if non-optional, it should have been a 'when', else if optional, it an additional optional relation, or additional roots to the 'when' relation are required.

If the 'where' involves an output pattern re-search, the search should be performed by the caller.