| Re: [qvtd-dev] [Dev]QVTi unbound variables |
Hi Horacio
You're neglecting the transitivity so:
The middle bottom can access the middle guard variables.
The middle guard variables can access the left/right guard variables.
So clearly the middle bottom can access the left/right guard variables.
Mark it up for clarification in: 9.4 and 9.17.6
Regards
Ed
On 01/03/2013 12:25, Horacio Hoyos Rodriguez wrote:Hi Ed,
I’ve been working on implementing the guard pattern visit methods and had a closer look at this. In the QVT Specification it says, regarding mappings:
“A mapping has one middle area and zero or more core domains. The guard pattern of the middle area depends on all the
guard patterns of all the domains. The bottom pattern of the middle area depends on all the bottom patterns of all the
domains. Thus, we may use the variables declared in the patterns of all the domain areas in the predicates and
assignments of the pattern of the middle area (provided that they are at the same level, i.e., both guard patterns or both
bottom patterns). The matching of the middle pattern uses all the valid bindings established during the matching of all the
domain patterns.”
With the important part being that variables declared in the domains of the mapping can be used in the middle area if the patterns in which they are used are at the same level. Thus, a variable defined in the guard pattern of the input domain cannot be used in the bottom pattern of the middle area. So in the following example:
map upper2lower in copyGraph {
map {
check upperGraph(g1:Graph |) {
}
where () {
realize g2g:Graph2Graph |
g2g.graph1 := g1;
}
map {
where () {
g2g.name := g1.name.toLowerCase();
}
}
}
The assignment g2g.graph1 := g1; is not valid because g1 is defined in the GuardPattern of the L domain and the assignment is in the BottomPattern of the middle area.
Horacio Hoyos Rodríguez
EngD Student
University of York
From: qvtd-dev-bounces@xxxxxxxxxxx [mailto:qvtd-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Willink
Sent: 18 January 2013 15:41
To: QVTD developers mailing list
Subject: Re: [qvtd-dev] [Dev]QVTi unbound variables
Hi
Within the current Area, an unbound Variable could be introduced in the BottomPattern, but there is no need to do so, so why allow unnecessary flexibility in what is intended to be a minimal flexibility representation?
More generally an unbound Variable might be referenced by a nested Pattern. If the Variable was in the BottomPattern, then the nested mapping would be similarly constrained. Restricting the declaration to the Guard avoids spurious restrictions on nested Mappings.
The possibility of 0 rather than 1 unbound variable we discussed and agreed that it was certainly necessary for top level structuring and might be appropriate for nested structuring too; further experience to guide semantics.
Regards
Ed
On 18/01/2013 12:32, Horacio Hoyos Rodriguez wrote:Hello,
On the small description of QVTi in the QVTd wiki (http://wiki.eclipse.org/M2M/QVT_Declarative_Languages) it says that at each node (mapping) a new unbound variable is introduced by one of the input (domain) or middle guard patterns. What is the rationale behind this restriction? I understand limiting the number of unbound variables to 1 enforces the loop semantics of nested mappings, but I don’t understand why they should be introduced in guard patterns.
From a semantics view, I would think of guards as IF..THEN conditions. So variables and predicates in guard patterns should only be used to condition the evaluation of domains and middle bottom patterns. Additionally, if we consider the base structure of a QVTi transformation:
map container in transformation {
map { -- L to M
check L() {
}
…
}
map { -- M To R
…
}
}
Does having a guard in the first domains (the check L() in the example) makes sense? If it doesn’t and these initial domains are an exception then the proposed ocl invariant should reflect this.
Personally I think that the unbound variable should be introduced in check domains (L to M) or in MiddleBottomPatterns (M to R).
Regards,
Horacio Hoyos Rodríguez
EngD Student
University of York
_______________________________________________qvtd-dev mailing listqvtd-dev@xxxxxxxxxxxhttp://dev.eclipse.org/mailman/listinfo/qvtd-dev
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2639/6039 - Release Date: 01/17/13
_______________________________________________ qvtd-dev mailing list qvtd-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/qvtd-dev
Version: 2013.0.2899 / Virus Database: 2641/6138 - Release Date: 02/28/13
_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvtd-dev