The semantics of EXTENDS and OVERRIDES
Tassilo Horn
I'm struggeling to understand the exact semantics of EXTENDS and
OVERRIDES. In this group, I've found only a message of Michael Lawley
where he says that the semantics are specified in various papers on
model transformation linked from http://www.dstc.edu.au/ which is dead
and gone now.
Now I've spent nearly one day searching for and reading papers of
Michael Lawley, Keith Duddy and friends. Unfortunately, all that I've
found only speaks very informally about extends and supersedes, which is
said to be obsolete now.
At least for EXTENDS I've found an example in "Model Transformation: A
declarative, reusable patterns approach". There we have:
--8<---------------cut here---------------start------------->8---
RULE cd(CD)
FORALL CCA::CompositeData CD
MAKE Java::Interface JIFace,
JIFace.name = CD.name
RULE cda(A, CD) extends cd(CD)
FORALL CCA::CompositeData CD,
CCA::Attribute A,
CCA::DataType Type
WHERE cdmap LINKS CD to JIFace
AND dtmap LINKS Type to JType
AND CD.feature = A
AND A.type = Type
MAKE Java::Interface JIFace,
Java::Attribute JAttr,
Java::Type JType,
JIFace.attributes = JAttr,
JAttr.name = A.name,
JAttr.type = JType
--8<---------------cut here---------------end--------------->8---
The explanatory text says:
The following rule, cda, extends the previous rule, cd, meaning that
it is applied to exactly those instances of CCA CompositeData matched
by the source expression of the rule cd.
Do I get it right, that cda is applied to only these CompositeData
instances that are attributed, and else the normal cd rule is applied?
And why do I need to write identical code in cd and cda in both the
FORALL and the MAKE? I would have expected that both CDs are unified,
and the MAKEs of the extended rules will always be applied, so that the
extending rule cda only adds "extensions" to both source and target
expression, e.g. I had expected something like this:
--8<---------------cut here---------------start------------->8---
RULE cda(A, CD) extends cd(CD)
FORALL CCA::Attribute A,
CCA::DataType Type
WHERE cdmap LINKS CD to JIFace
AND dtmap LINKS Type to JType
AND CD.feature = A
AND A.type = Type
MAKE Java::Attribute JAttr,
Java::Type JType,
JIFace.attributes = JAttr,
JAttr.name = A.name,
JAttr.type = JType
--8<---------------cut here---------------end--------------->8---
Strange enough: why does the original cda rule not set JIFace.name?
Ok, so you see, I'm pretty confused with the exact EXTENDS semantics.
Could someone please try to explain it to me?
And with regards to OVERRIDES, I'm totally lost. As already said, I
could only find brief explanations of the obsolete supersedes. Again,
could someone explain it to me?
Thanks a ton in advance,
Tassilo
Kerry Raymond
RULE B EXTENDS RULE A ...
This pretty much means that Rule B does everything that rule A does plus
whatever rule B says. The use of the name "EXTENDS" was to try to capture
the notion of an inheritance hierarchy in the RULEs, as the most obvious use
of RULE EXTENSION is generally to have one RULE that works on some supertype
and the EXTENDS Rules that work on its various sub-types doing some
additional things specific to that subtype. Well, that was the idea, but it
never really turned out to be quite as useful as we hoped.
But the semantics are if a pattern in the source matches both RULE A and
RULE B, then the combination of RULE A and RULE B are applied.
RULE A ...
RULE B SUPERSEDES RULE A ...
Again the motivation for this was driven by the desire for a hierarchy of
rules that sort-of aligned with the type hierarchies of things to be
transformed in the source. But in this case, the idea was that a subtype was
to be processed quite differently to its supertype. So if a pattern in the
source matches both RULE A and RULE B, then only RULE B is applied (and not
RULE A).
On the surface this seems a useful enough thing to do. In practice, again,
we found that the semantics for SUPERSEDES could get really complicated. And
frankly what the tefkat engine would do in some of those cases (or should
do) wasn't obvious. While the motivation was based on type inheritance, the
reality is that Tefkat works with source patterns, not source types, and so
the ideas of super/sub-patterns is not well-understood.
So yes SUPERSEDEs is available in Tefkat, but whether or not it does what
you expect it to do is a matter for experimentation. In simple cases, it
will probably do what you expect. In complicated cases, it's hard to say
either what you should expect or what it will do :-)
We pretty much stopped using both EXTENDS and SUPERSEDES in our own
transformations, because they didn't actually make it any easier to write
transformations. A nice idea but ...
Kerry
Hi all,
The explanatory text says:
--
You received this message because you are subscribed to the Google Groups
"Tefkat" group.
To post to this group, send an email to tef...@googlegroups.com.
To unsubscribe from this group, send email to
tefkat+un...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/tefkat?hl=en-GB.
Tassilo Horn
Hi Kerry,
> RULE A ...
>
> RULE B EXTENDS RULE A ...
>
> This pretty much means that Rule B does everything that rule A does
> plus whatever rule B says. The use of the name "EXTENDS" was to try to
> capture the notion of an inheritance hierarchy in the RULEs, as the
> most obvious use of RULE EXTENSION is generally to have one RULE that
> works on some supertype and the EXTENDS Rules that work on its various
> sub-types doing some additional things specific to that subtype. Well,
> that was the idea, but it never really turned out to be quite as
> useful as we hoped.
That's what I was guessing, too. But then, why are A's source and
target patterns (partly) copied into the extending rule B. In my
example, why is the CompositeData CD matched in cd and cda, and why is
the Interface JIFace made in both? I would have expected that rule cda
inherits these patterns. For the name-setting of JIFace, that seems to
be the case.
> But the semantics are if a pattern in the source matches both RULE A and
> RULE B, then the combination of RULE A and RULE B are applied.
Does that mean, that the combination of e.g. target patterns unifies
JIFace in both rules, and indeed it could have been left out of cda?
> RULE A ...
>
> RULE B SUPERSEDES RULE A ...
>
> Again the motivation for this was driven by the desire for a hierarchy of
> rules that sort-of aligned with the type hierarchies of things to be
> transformed in the source. But in this case, the idea was that a subtype was
> to be processed quite differently to its supertype. So if a pattern in the
> source matches both RULE A and RULE B, then only RULE B is applied (and not
> RULE A).
Ah, ok. So that's pretty similar like a overridden Java method without
super call, right?
But since SUPERSEDES is obsolete anyway, what's OVERRIDES? In
principle, your description of SUPERSEDES is pretty much what I would
have expected from OVERRIDES.
Bye,
Tassilo
michael lawley
One of the "issues" we ran into with this stuff is that the language
spec was originally defined independently of the concrete syntax but
also left out/got wrong a couple of details (the key one in this case,
I think, was that EXTENDS et al should probably have introduced new
scopes rather than behaving like macro expansion because, it turns
out, that you often want to extend certain kinds of rules multiple
times but with different, independent variable bindings).
Some of these issues weren't apparent until we devised the concrete
syntax and then implemented and used it.
Looking again at the example you quote, I think there's probably a bug
(or two) in there. To properly understand what's going on one needs
to make all the implicit FROM clauses explicit, giving:
RULE cd(CD)
FORALL CCA::CompositeData CD
MAKE Java::Interface JIFace FROM cd(CD),
JIFace.name = CD.name;
RULE cda(A, CD) EXTENDS cd(CD)
FORALL CCA::CompositeData CD,
CCA::Attribute A,
CCA::DataType Type
WHERE cdmap LINKS CD to JIFace
AND dtmap LINKS Type to JType
AND CD.feature = A
AND A.type = Type
MAKE Java::Interface JIFace FROM cda(CD, A, Type),
Java::Attribute JAttr FROM cda(CD, A, Type),
Java::Type JType FROM cda(CD, A, Type),
JIFace.attributes = JAttr,
JAttr.name = A.name,
JAttr.type = JType;
If we then "unroll" the EXTENDS clause we get
RULE cda(A, CD)
FORALL CCA::CompositeData CD,
CCA::Attribute A,
CCA::DataType Type,
CCA::CompositeData CD // from cd
WHERE cdmap LINKS CD to JIFace
AND dtmap LINKS Type to JType
AND CD.feature = A
AND A.type = Type
MAKE Java::Interface JIFace FROM cda(CD, A, Type),
Java::Attribute JAttr FROM cda(CD, A, Type),
Java::Type JType FROM cda(CD, A, Type),
JIFace.attributes = JAttr,
JAttr.name = A.name,
JAttr.type = JType,
Java::Interface JIFace FROM cd(CD), // from cd
JIFace.name = CD.name; // from cd
Note how the target side of cd gets copied into cda as well and thus
the JIFace.name assignment doesn't need repeating. The repetition of
the "MAKE Java::Interface JIFace", is also seems redundant, however
the implicit FROM is different and thus introduces a bug as the rule
will fail as soon as an CompositeData with more than one Attribute
feature is matched (the inherited FROM cd(CD) means there can only be
one JIFace per CompositeData but the FROM(CD,A,Type) will require
there to be more than one).
As to why both SUPERSEDES and OVERRIDES, well there were many long
long discussions about them and IIRC it largely came down to
SUPERSEDES being what one normally wants, but there being things you
might want to express that you couldn't using EXTENDS & SUPERSEDES.
OVERRIDES was then the "orthogonal" operator that you needed but when
combined with EXTENDS gave the SUPERSEDES semantics.
michael
Tassilo Horn
Hi Michael,
Great, your explanation makes perfectly sense. I think the intension of
the rules is indeed to have one JIFace, so cda should strip that from
the MAKE, and the CCA::CompositeData CD could also be left out from cda,
because it's inherited from cd anyway, right?
> As to why both SUPERSEDES and OVERRIDES, well there were many long
> long discussions about them and IIRC it largely came down to
> SUPERSEDES being what one normally wants, but there being things you
> might want to express that you couldn't using EXTENDS & SUPERSEDES.
> OVERRIDES was then the "orthogonal" operator that you needed but when
> combined with EXTENDS gave the SUPERSEDES semantics.
Ok, but both EXTENDing and OVERRIDing one rule are forbidden.
Do I get it right with these statements?
- A EXTENDS B: Combines/unifies source and target patterns by
including B in A.
- A SUPERSEDES B: The source pattern is combined like with A EXTENDS
B, but the target pattern of B completely replaces that of A. If
the A's source pattern doesn't match but B's does, then B's original
target pattern does its job anyway.
- A OVERRIDES B: A completely removes B.
Bye,
Tassilo