Am 26.06.2017 um 13:50 schrieb Steffen
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'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
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.
- 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
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
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
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).
- 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?
- 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
- 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.
Any pointers would be most useful :-)
Steffen and Kinga
Dr. rer. nat. Steffen Zschaler AHEA
King's College London
Department of Informatics
Phone +44 (020) 7848 1513
henshin-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit