[qvtr] Implicit-when and null-when semantics

[eclipse-qvtd-bot]

| --- | --- | | Bugzilla Link | 500254 | | Status | NEW | | Importance | P3 enhancement | | Reported | Aug 25, 2016 05:04 EDT | | Modified | Dec 15, 2016 07:32 EDT | | Depends on | 412341 | | Blocks | 509281 | | Reporter | Ed Willink |

Description

The GIT\mmt\qvt\docs\EXE2016\MicroMappings.pdf example provides an interesting comparison between ATL and QVTr syntax in which the bidirectional QVTr bloat is apparent.

Suggest, for the common case where there is only a single candidate for conversion of E to Edash that when E2Edash can be subsumed by an ATL like operator so that

headElement = forwardHead : Element{}
...\
headElement = reverseHead : Element{}
...\
when {\
    element2element(forwardHead, reverseHead);\
}

can be written as:

headElement <- forwardHead
...\
headElement <- reverseHead\
\

The <- providing a shortform form for the QVTo-like

headElement = forwardHead.resolveIn(element2element)
...\
headElement = reverseHead.resolveIn(element2element)

where the QVTo-like syntax could be an alternative to a when clause but obviously needs to be multi-directionally redundant.

---

The shortform and its long form solves another problem. How is the mapping applied to an emptylist in which headElement is null? element2element(forwardHead, reverseHead) presumably fails for null, so the overall mapping fails. It is necessary to provide an alternative relation to explicitly handle the root case.

The expression-like ATL or above shortform, in contrast to the QVTr when declaration, handles null naturally; no additional relation is needed. This suggests that for consistency, at least a 1:1 relation is true for null. i.e. element2element(null, null) is true.

?? can all multi-term when clauses be normalized into QVTo-like resolve expressions ??

Rather than QVTo-like, perhaps QVTc-like

headElement = forwardHead.Telement2element.reverseElement
...\
headElement = reverseHead.Telement2element.forwardElement

[eclipse-qvtd-bot]

By Ed Willink on Oct 05, 2016 15:40

(In reply to Ed Willink from comment #0)

can be subsumed by an ATL like operator so that

It is too early for radical QVTr syntax tweaks and perhaps it is better to have ATL syntax available as an alternative when simple unidirectional is needed.

--

The null problem must be addressed. How does

when {\
  element2element(forwardList.headElement, reverseList.headElement);\
}

pass for null headElement?

We could modify element2element to allow a [?] input, so that null propagates to a degenerate mapping, but confusing element2element for definitely-an-element with may-be-an-element seems really bad.

We could add a guard

when {\
  forwardList.headElement <> null or reverseList.headElement <> null\
  implies element2element(forwardList.headElement, reverseList.headElement);\
}

but we have to recognize the idiom and in the forward direction is it valid to test reverseList.headElement?

We could have an explicit prefix such as "optional", "?" or suffix such as "[?]"

when {\
    element2element(forwardList.headElement, reverseList.headElement)[?];\
}

In the case of multi-rooted / multi-directional I think ALL arguments must be null for the null-when match. Mixes and matches can be hand coded.

If we put a [?] suffix on the arguments it handles many mixes and matches too.

when {\
    element2element(forwardList.headElement[?], reverseList.headElement[?]);\
}

Prefixes may avoid some syntax ambiguity parsing challenges:

when {\
    element2element(optional forwardList.headElement, optional reverseList.headElement);\
}

Specifying two optional's is tedious, so an overall prefix if all arguments are optional.

when {\
    optional element2element(forwardList.headElement, reverseList.headElement);\
}

[eclipse-qvtd-bot]

By Ed Willink on Oct 12, 2016 07:30

Doh! when {} is for a mandatory match. If an optional match is required it should be a where {}.

The foregoing discussion is therefore INVALID.

Residual issue. Why is there no helpful warning driving the user from an illegal when{} to a where{}?

[eclipse-qvtd-bot]

By Ed Willink on Oct 12, 2016 08:44

(In reply to Ed Willink from comment #2)

If an optional match is required it should be a where {}.

First attempt at recoding left optional parts in the caller and execution failed.\ Consistent extraction of all the optional part to a where mapping and it works. (Provided, Bug 505788, the stale middle Java model is deleted to permit regeneration.)

The correct recoding is more verbose than the emptyList2emptyList special case workaround.\

Residual issue. Why is there no helpful warning driving the user from an illegal when{} to a where{}?

?? use of optional multiplicity elements in domain/when-patterns is illegal since the domain/when-patterns describe one exact leaf truth wrt the iterations pf collection terms. ?? explicit null is not optional for the purposes of the preceding check.

[eclipse-qvtd-bot]

By Ed Willink on Oct 12, 2016 12:03

(In reply to Ed Willink from comment #3)

Residual issue. Why is there no helpful warning driving the user from an illegal when{} to a where{}?

?? use of optional multiplicity elements in domain/when-patterns is illegal since the domain/when-patterns describe one exact leaf truth wrt the iterations pf collection terms. ?? explicit null is not optional for the purposes of the preceding check.

Bug 412341 should support a QVTrelation.ocl into which such WFRs can be placed.