Re: [henshin-dev] multiRule Interpreter

[Enrico Biermann <enrico@xxxxxxxxxxxxxxx>]

Hi,

I will take a look at it, but probably not before the weekend.

Regards,
Enrico

On 16.01.2012 14:05, Gregor Bonifer wrote:
> 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
>>
>
> _______________________________________________
> henshin-dev mailing list
> henshin-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/henshin-dev