Re: [henshin-dev] multiRule Interpreter

[Gregor Bonifer <gregor.bonifer@xxxxxx>]

With respect to the release plan we should really take care of this 
asap. In order to become stable till march someone should read the code 
within the next week.
@enrico: Will you find the time to assess the code and the design 
decisions?
@all: Please let me know if you have any experience with the 
interpretation of multiRules. To get an overview it is also helpful to 
get feedback on successful usage.

Regards,
Gregor

Am 21.12.2011 20:16, schrieb Christian Krause:
> Hi Gregor,
>
> I'm glad that you were able to come up with a prototype so quickly. 
> Thanks a lot. I cannot judge whether your design decisions and the 
> implementation details are reasonable and correct. I think the best 
> person to judge this is Enrico. To me, your design decisions sound 
> good though.
>
> Just one remark: you wrote "the kernel must not be mapped entirely 
> into each multiRule" -- I assume that is just a grammar mistake and 
> you actually meant that the kernel rule is not needed to be mapped 
> entirely (it can be mapped partially). That is at least what we 
> discussed.
>
> My suggestion for the next steps would be that first Enrico takes a 
> look at your code and then we implement some tests to check whether 
> everything works as expected. I am also keen to try out some examples 
> with nested amalgamation in the state space tools. :)
>
> Cheers and happy holidays,
> Christian
>
> On 12/21/2011 03:39 PM, Gregor Bonifer wrote:
> > Hi,
> >
> > I checked in a beta version of the interpreter under 
> > branches/multiRuleInterpreter. Consider this a proposal! I made a 
> > change to Match that might be a bit controversial but works just 
> > fine. So, here is the outline of what I have done:
> > - private Map<Rule, List<Match>> Match.nestedMatches: A match holds a 
> > map that contains a collection of matches for each multiRules. For 
> > Rules without multiRules this simply remains empty.
> > - EmfEngine:
> > -- findMatch and findAllMatches work recursive to build a Match-tree 
> > using an altered version of prepareMatchFinder, that allows injecting 
> > usedObjects and prematches.
> > -- executeModelChanges accumulates the changes from a Match-tree into 
> > a ModelChange-Object that is passed recursively(much easier that 
> > merging two ChangeDescriptors). The traversal yields another 
> > Match-tree representing the comatch.
> >
> > For this to work, there is one important constraint for the 
> > transformation model: As we discussed earlier, the kernel must not be 
> > mapped entirely into each multiRule. However, if a kernelNode is 
> > mapped inside the kernelRule(i.e. the node is preserved), either both 
> > or none of the kernelNodes must be mapped into a multiRule. In case 
> > both nodes are mapped there also has to be a mapping between the two 
> > inside the multiRule.
> >
> > Regards,
> > Gregor
> >
> > _______________________________________________
> > 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