Hello Gregor,
this approach is too complicated. The actual implementation is
pretty simple. You need to construct a big rule from a set of
matches. The code for this functionality is already present in the
class AmalgamationInfo and can be reused for nesting. We don't need
another Matchfinder or remove the seperation between Engine and
Matchfinder. The only difficult part is the decision what kind of
amalgamated rule should be created:
- locally injective vs. globally injective
- meaning of the notion "all matches of a nested rule" i.e. "Is
construction for a specificy match unique?"
The current implementation corresponds to the theory. There are
three different approaches to amalgamation which mostly differ in
the construction of the amalgamated rule:
- unique construction (Models08 and SoSym10 if I recall correctly)
- weakly-independent
- weakly-disjoint
With unique construction all matches for all multi-rules are
considered. This will always yield a unique rule but it might not be
applicable because its gluing condition is violated (if one
multi-rule match preserves a node and another multi-rule match
deletes the node). This is the strategy used by the current
implementation.
Weakly-independent allows overlapping outside the kernel rule but
requires that part of the match to be independent (for example
multi-rules may overlap if they both preserve the common structure).
Weakly disjoint means no overlapping outside the kernel rule at all.
The problem with the latter two approaches is their
non-deterministic result. Normally rule applications are
deterministic given a specific match. When you discard certain
matches (which is necessary to ensure independence or disjoint
coverage) you create a new kind of non-determinism which is even
worse in the case of nesting because given a specific strategy
certain "matches" are lost entirely. In most examples where
amalgamation is used all three constructions are the same because
even when using weakly-disjoint or weakly-independent a unique
result is usually desired.
Before starting with the implementation we should discuss which kind
of amalgamation we really want to have. I described the different
flavors in my last mail. Personally I think the most useful and
simplest solution is locally injective matches (depending on the
trafo option) and unique construction. This implementation would
only require the extension of AmalgamationInfo to handle recursion
on the matches. But even more complex strategies can be implemented
with a single class with similiar functionality to AmalgamationInfo
(but a more complex approach to the detection of matches).
Regards,
Enrico
On 13.12.2011 13:55, Gregor Bonifer wrote:
Well, first of all we need nested amalgamation. I think this alone
justifies a larger amount of code than we will actually need. How
far this means code changes or code additions is yet to decide.
After all we not just added some special case, but we changed the
single most important entity of the transformation model: the
rule.
Second, as far as my judgement goes, I am wondering if the current
implementation of AmalagamationUnit conforms with any theoretical
approach.
Regarding the implementation: At the moment the separation between
interpreter and matching works fine, because of the static nature
of a Rule. For Rule schemes this is not the case. Therefore the
first question would be whether we want a SchemeMatchFinder(which
would use the MatchFinder) that may be used independently of the
interpreter like the current (static) Matchfinder. This would
require the dynamic creation of new Matchfinders, which again
would require exposure of VariableInfo to the SchemeMatchFinder.
Do we want that?
Regards,
Gregor
Am 13.12.2011 11:14, schrieb Stefan Jurack:
Am 12.12.2011 17:45, schrieb Enrico Biermann:
My approach
would have been local injectivity (for a single match in a single layer
of one rule) and unique construction of the nested amalgamated rule
(even if the resulting rule is not applicable due to dangling or
identification conditions.
Yep.
However, local injectivity works for the present implementation due to
the full embedding of the the kernel's Lhs/Rhs into the multi rules. If
Gregor implements the interpreter along the new approach of embedding
required nodes only, he should make sure that the semantics/behavior
remain as is.
I am also interested in the amount of code change that comes with these
changes. @Gregor, what is your estimation: It the amount reasonable?
Regards, Stefan
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
|