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
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 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.2890 / Virus Database: 2639/6039 - Release
Date: 01/17/13