| Re: [henshin-dev] Proposal to remove direct creation of edges |
|
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. |