eclipse-qvtd-bot
commented
2 weeks ago By Ed Willink on Jun 25, 2019 06:12
(In reply to Ed Willink from comment #0)
If we encode the directionality by root variables corresponding to:
ecore:{EClassifier,ordered,unique,lower,upper}, pivot:Type
we sensibly map a tuple to a type.
Once the support for non-top abstract when is sorted, the tuple is variously in the root-variables / trace.
| --- | --- | | Bugzilla Link | 548536 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 22, 2019 03:49 EDT | | Modified | Jun 28, 2019 04:47 EDT | | Depends on | 548738 | | Blocks | 529207 | | See also | 512532, 530054 | | Reporter | Ed Willink |
Description
This proves to be a challenging mapping justifying its own bug.
For a single nested collection:
ETypedElement.{eType,ordered,unique,lower,upper} <=> TypedElement.type
where five distributed Ecore features map to one Pivot derived CollectionType.
Compound Pivot types are shared singletons in the Orphanage, Compound Ecore types are repeated paramneterization of a container.
We therefore need an N-to-1 mapping, but a mapping instance is 1-to-1. Therefore inclusion of the ETypedElement in the pattern will give multiple Pivot types.
Perhaps a key solves the problem and we clearly have distinct SetType, BagType keys rather than an inherited CollectionType key. But we would like keys to just be syntax sugar, so how do we solve the problem without keys?
The ordered,unique,lower,upper features could be primitve domain inputs, but if we have root variables corresponding to:
ecore:EClassifier, primitive:{ordered,unique,lower,upper}, pivot:Type
from ecore to pivot the primitives are inputs, whereas from pivot to ecore the primitives are outputs which seems unpleasantly irregular and contrary to 7.2.4 "Simple data such as configuration information or constants may be passed as parameters to a relation using primitive domains." Clearly an input only capability.
If we encode the directionality by root variables corresponding to:
ecore:{EClassifier,ordered,unique,lower,upper}, pivot:Type
we sensibly map a tuple to a type. The multiple non-top when invocations perform the shared mapping provided we accept the use of a DataType input/head. Use of a 'tuple' avoids any 5-dimensional search stupidities.
Structurally each non-top when invocation creates a distinct invocation trace instance, each of which references a shared invoked execution trace instance.
(Must be a non-top to allow the caller to present the Ecore tuple, must be when to allow the caller to assign the result to the ETypedElement/TypedElement.)