|
Hi Daniel,
Many thanks for your detailed response, which we will study in
detail and aim to apply to our problem as much as possible.
I think part of the problem with PACs was that we actually needed to
change something in the part of the graph that was matched by the
multi-nodes. So, putting one of these into a PAC would mean it would
no longer be matched by the multi-nodes and, thus, would not see the
effect of the change.
For the create-semantics, can I just check that I understood this
correctly: For cases like C, Henshin will essentially produce the
cross-product of all matches either side and then execute the
create/delete logic for each combination? Would it be correct, then,
to say that there is no inherent way of controlling this assignment?
We have a particularly annoying example at our hands at the moment
that would require something like this. Trying to translate this
into your simple chairs/tables/guests example, one could perhaps say
that we
- Need to create a number of guests; guests have a name, which
is selected from a limited pool of available names.
- Need to create a chair for each guest.
- Need to place a guest's chair at the table reserved for guests
of this name; that is, some guests will share a table if they
have the same name.
Ideally, we would like to make this work within a single rule. It
seems, however, from your explanation that this might not be
possible. I'm not sure, however, I can figure out how I would do
this with a combination of rules either (note that the pool of
names is defined in the model (essentially because there is a
fixed set of tables one for each name), so it's not a simple
matter of calling the same rule with different parameters.
Any ideas/pointers?
Many thanks,
Steffen
On 26/06/2017 15:22, Daniel Strüber
wrote:
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
- 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.
- 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
_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://emea01.safelinks.protection.outlook.com/?url="">
--
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/
|
