[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [qvtd-dev] Mapping composition
|
Hi,
I think I didn't make myself clear. Suppose we have my original example to
copy a Graph:
map upper2lowerLM in copyGraph {
-- L to M for G
check upperGraph(g1:Graph |) { }
where () {
realize g2g:Graph2Graph |
g2g.graph1 := g1;
}
map {
where () {
g2g.name := g1.name.toLowerCase();
}
}
map { --
L to M for N
check upperGraph(n1:Node | n1.graph = g1;) { }
where () {
realize n2n:Node2Node |
n2n.owner := g2g;
n2n.node1 := n1;
}
map {
where () {
n2n.label := n1.label.toLowerCase();
}
}
}
}
If no mapping composition is allowed, then the map for Nodes must be moved
to the root:
map upper2lowerLMNode in copyGraph {
-- L to M for N
check upperGraph(n1:Node | n1.graph = g1;) { }
where () {
realize n2n:Node2Node |
n2n.owner := g2g;
n2n.node1 := n1;
}
map {
where () {
n2n.label := n1.label.toLowerCase();
}
}
}
However, the GuardPattern of the L Domain has a reference to g1 (that was
defined in the outer mapping in the original transformation). g1 is
undefined for this mapping, so we would require to define it somehow:
map upper2lowerLMNode in copyGraph {
-- L to M for N
check upperGraph(g1:Grapg, n1:Node | n1.graph = g1;) { }
...
Which violates the constraint of 1 unbound variable per guard pattern. The
other option is to move the restriction on n1's parent to the middle
model, as the example in my previous email (which follows the idea in the
ColorTree example), which introduces the concerns I mentioned.
What I am trying to show is that we need to support both idioms: mapping
composition and mapping call.
Horacio Hoyos RodrÃguez
EngD Student
University of York
-----Original Message-----
From: qvtd-dev-bounces@xxxxxxxxxxx [mailto:qvtd-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ed Willink
Sent: 08 March 2013 16:00
To: QVTD developers mailing list
Subject: Re: [qvtd-dev] Mapping composition
Hi
I don't see the difference with
map HSV2MiddleRecursion in ColorChanger {
hsv(hsvNode : HSVNode | ) {}
where(middleParent : HSVNode2HLSNode | ) {
realize middleNode : HSVNode2HLSNode |
middleNode.parent := middleParent;
middleNode.hsv := hsvNode;
middleNode.rgb := hsv2rgb(hsvNode.hsv);
}
map HSV2MiddleRecursion {
hsvNode := hsvNode.children;
middleParent := middleNode;
}
}
where the 'nested' mapping has two unbound variables, one bound to a
parent and the other to each child in turn.
A 'nested' mapping, just like a function, can have as many passed
variables as required.
The QVTi simplification is one new unbound variable at a time; not just
one unbound variable in total.
[However since the nested mapping call is just a loop, I'm not sure that
multiple loops are really much of a problem anyway; the binding order
couyld impose the search order.]
Regards
Ed
On 08/03/2013 15:35, Horacio Hoyos Rodriguez wrote:
> Hi Ed,
>
> I've started some tests and I think we need to rethink the composed
> mappings a bit more. Looking at my simple Graph transformation and at
> the UML2RDBMS it seems we still need composed mappings. For example in
> the Graph transformation, the composed mapping that transforms nodes
> of a
> graph:
>
> ...
> map { --
> L to M for N
> check upperGraph(n1:Node | n1.graph = g1;) { }
> where () {
> realize n2n:Node2Node |
> n2n.owner := g2g;
> n2n.node1 := n1;
> }
> map {
> where () {
> n2n.label := n1.label.toLowerCase();
> }
> }
> }
>
> So far I have not been able to come up with a way to move this mapping
> to the root and invoke it via a MappingCall, basically because I lose
> the reference to g1 and that would mean that in a non-composed mapping
> I would
>
> need 2 unbound variables: n1 and g1. Perhaps, as in the ColorTree
> example,
>
> the association to the parent graph of G1 can be done through the
> middle
> model:
>
> map NodeLM in copyGraph {
> -- L to M for N
> check upperGraph(n1:Node |) { }
> where (g2g:Graph2Graph | g2g.graph1 := n1.graph;) {
> realize n2n:Node2Node |
> n2n.owner := g2g;
> n2n.node1 := n1;
> }
> map {
> where () {
> n2n.label := n1.label.toLowerCase();
> }
> }
> }
>
> However, as in the future this transformation is derived from a QVTc
> one, I believe that if the original QVTc transformation had the
> composed mapping using g1 it would be hard to replace a predicate at
> the L model (n1.graph = g1;)) by one at the middle model (g2g.graph1 :=
n1.graph;).
> Probably with this example it seems not that hard but I am guessing we
> would have a challenge devising a strategy that correctly transforms L
> predicates into M predicates.
>
> Regards,
>
>
> Horacio Hoyos RodrÃguez
> EngD Student
> University of York
>
> -----Original Message-----
> From: qvtd-dev-bounces@xxxxxxxxxxx
> [mailto:qvtd-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Ed Willink
> Sent: 08 March 2013 14:35
> To: qvtd-dev@xxxxxxxxxxx
> Subject: [qvtd-dev] Distinct QVTi editor
>
> Hi Horacio
>
> The distinct QVTi editor is now available on GIT master. Attached is a
> patch that eliminates the compilation errors in your plugins; no
> guarantee
>
> that the fixes are actually correct.
>
> A number of name changes are inevitable; e.g ImperativeModel rather
> than CoreModel. QVTimperativeVisitor rather than QVTcoreVisitor.
>
> Many names have been promoted to QVTcoreBase that is common to QVTcore
> and
>
> QVTimperative.
>
> I've eliminated the MappingCall from QVTc and the composed/refined
> mappings from QVTi. Anything else fundamental that should change?
>
> Regards
>
> Ed
> _______________________________________________
> qvtd-dev mailing list
> qvtd-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/qvtd-dev
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2904 / Virus Database: 2641/6155 - Release Date:
> 03/07/13
>
>
>
_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvtd-dev
