Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [henshin-user] Multi-rules questions
Hi Steffen,

Am 26.06.2017 um 13:50 schrieb Steffen Zschaler:

We're trying to make sense of multi-rules in Henshin and what their exact semantics are. We've built some fairly complex rules which are meant to match all occurrences of a particular pattern and make a consistent set of modifications to this set in one go. Below, I list some questions we have come across, but haven't really found any responses to. Is there a more detailed tutorial / documentation document somewhere that we just haven't found yet or could someone help us understand what is going on here?

You're indeed using multi-rules for the right purpose, but it seems like multi-rules in their current form may be not expressive enough for supporting your use-case. In particular, unfortunately, there is no idiomatic way to have non-optional multi-rules.

We do have some documentation for the usage of multi-rules (e.g., [1,2]), but it's mostly limited to cases where the simple "for-each" semantics of (optional) multi-rules is sufficient. I'm also CC-ing Gabi, since she might know some additional resources.

[1] https://www.eclipse.org/henshin/examples.php?example=ecore2rdb
[2] http://www.ckrause.org/2013/01/nested-multi-rules-in-henshin.html


  1. Multi-nodes seem to be optional. That is, if a multi-node cannot be matched, the rule will still be matched and executed. We need to say that the multi-node needs to be matched at least once. We have tried adding a PAC using a <<requires>> patterns, but that just seems to have stopped the rule from matching at all. We have also tried "loop unwinding" the multi-node once, but that seems to require duplicating all the pattern and all the changes that go with it, which becomes quite cumbersome and creates additional problems (see below). What is the recommended way to go about this?

A pragmatical, slightly dirty way of avoiding the pattern duplication is to "preprocess" your rules before you apply them, by introducing the duplication only in the in-memory representation, rather than the transformation editor. The implementation effort for this step would be smallish, but of course, there might be drawbacks.

More soundly, one could implement a small extension of the Henshin language: the EClass "Rule" could have an additional EReference "requiredMultiRules". In the graphical editor, one could nicely indicate this distinction by using "+" rather than "*". This would be very clean, but, of course, come with greater implementation effort.

I actually found it surprising that the PAC approach didn't work - an example could be helpful here. But then again, the PAC approach actually seems to lead to the same pattern duplication as loop unwinding does.


  1. We are a bit unclear about how multi-nodes connect with simple nodes, especially where <<create>> elements are present. For example, if we want to say that all matches of a particular multi-node need to be connected to the same newly created object vs each one being connected to its own newly created object vs each one being connected to an object to be (possibly uniquely) selected object from the matches of another multi-node. Is there a discussion somewhere, which of these can/cannot be done and how they can be done?
In the attached image, I created three rules that cover these three cases. Case 1 and 2 are straightforward, whereas 3 requires some caution (see below).
  • Rule A takes a room with a number of guests and adds a matching number of chairs to the room. It also adds precisely one table, which is shared by all chairs.
  • Rule B adds a chair and a table for each guest. Afterwards, the numbers of guests, chairs, and tables in the room will match.
  • Rule C finds all pairs of guests and tables in the room. It then adds a chair for each such pair.

Taken as is, Rule C only works well in the case that you have precisely one table in the room. If you have m tables and n people, you get m*n chairs, which may overcrowd your room. Still, one can mitigate this issue by using a parameter in order to select a specific table to be used.


Best regards,
Daniel

Any pointers would be most useful :-)

Many thanks,

Steffen and Kinga

-- 
Dr. rer. nat. Steffen Zschaler AHEA
Senior Lecturer

King's College London
Department of Informatics

Email szschaler@xxxxxxx
Phone +44 (020) 7848 1513
WWW   http://www.steffen-zschaler.de/


_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-user

Attachment: tablesandchairs.png
Description: PNG image

Back to the top