[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 18:14 schrieb Steffen Zschaler:

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.
I see. I still think that the non-optional matching of multi-rules can be enfoced by using a PAC. But that PAC would need to fully duplicate the LHS of the multi-rule, and that's a bit unsatisfying, of course.


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?
Essentially yes. In the Henshin terminology, we don't say it's a cross-product of matches, but just the list of all matches for the multi-rule. In the C case, the length of this list is determined by the cross-product of tables and persons. The change actions specified in the multi-rule are applied to each multi-rule match, indeed.

Would it be correct, then, to say that there is no inherent way of controlling this assignment?
It depends on the desired assignment. Generally, identifiers can be very helpful to better control the assignment (see below).

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
  1. Need to create a number of guests; guests have a name, which is selected from a limited pool of available names.
  2. Need to create a chair for each guest.
  3. 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.

Making Reqs. 1, 2 and 3 work within the same rule seems impossible, since the guest-to-table assignment needs to be determined in the LHS, while the guests can only be created in the RHS. We would need to put the cart before the horse.

However, assuming that Req. 1 is fulfilled elsewhere, Req. 2 and 3 can be fulfilled by Rule D in the attached figure: It finds all guest-table pairs _with matching names_ and, for each such pair, creates and assigns a chair. Note the use of the variable x in the name attributes of guests and tables.

The implementation of Req. 1 can be quite tricky, and some more details about the example are required: Is the number of guests a fixed number, a user-specified parameter or a random number (in some user-specified bounds)? Is the pool of names fixed or user-specified?

Best regards,
Daniel

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


  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



_______________________________________________
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/


_______________________________________________
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: room.png
Description: PNG image