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