Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [henshin-dev] Injective Matching & Multi Nodes
Sorry last mail went off too fast... Here the complete one.

Cheers, Sebastian 

Am 07.10.2014 um 19:42 schrieb "Christian Krause" <henshin.ck@xxxxxxxxx>:

Hi Sebastian,

comments below...

2014-10-07 11:39 GMT+02:00 Sebastian Gabmeyer <sebastian.gabmeyer@xxxxxxxxxxxx>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I just realized that the injectivity of a match from LHS to the host
graph is enforced across NACs, that is, if a node n1:N from the LHS is
mapped to some node h:N in the host graph, a node n2:N in a NAC that
is not mapped to n1 cannot be mapped to h (this is correct, isn't
it?).  I was wondering if there are any theoratical restrictions that
require this behavior?  In essence, I expected that the NAC, if not
explicitly mapped to some node from the LHS, would map to _any_ node
(in particaluar, including any nodes mapped from the LHS to the host
graph), as this would simplify the specification of the NAC.


Injectivity can be specified per rule, or as an engine option. Therefore it is not possible to change the injectivity of matching just for NACs/PACs. It is correct that for NestedConditions, Henshin uses the default options, which means injective matching. I think this is not so much because of theoretical restrictions but rather to avoid unintended behavior.
 
So this essentially means that any node of the host graph matched by the LHS graph cannot be matched again by a NAC/PAC node, right?


Concerning multi-nodes I was wondering whether there is a semantic
difference between a NAC that contains multi-nodes and an equivalent
NAC where all multi-nodes have been replaced by single-nodes?  (To me
they'd be equivalent, as both would explore _all_ possible mappings).

These two versions have different behavior. If you use a normal NAC it restricts the applicability of the rule as a whole. NACs in multi-rules on the other hand restrict only the applicability of this multi-rule. It can be basically used to filter out some of the multi-matches. It does not have any influence on the kernel rule.
 
I see, I think the way I'm using multi nodes would probably qualify as abuse ;)  since we only use simple rules in our application scenario, that is, no units and no control flow, we add multi-nodes to rules to match zero or more nodes. Since we do not have a kernel rule, only deletion nodes seem to make sense in our context... Is there any problem using multi nodes as described here?


Further, are PAC multi-nodes actually redundant as the PAC is
satisfied if _zero_ or more nodes satisfy it, meaning that even if
there's no node present, the PAC would be satisfied anyway. 

Again, the PAC in this scenario restricts the applicability of the multi-rule, not the rule as a whole. Here is an example of a rule with multi-rule PAC: http://www.ckrause.org/2014/02/parallel-graph-pattern-matching-in.html
 
Finally,
is there a reasonable example where multi-nodes in the RHS make sense?


See the example above. It is often used when you have scenarios like: find all X with some property and create a Y for each of them. A more complex example is https://www.eclipse.org/henshin/examples.php?example=ecore2rdb
 
If I didn't state my question precise enough or if you need an
example, please let me know ;)


Cheers,
Christian
 
Best wishes, Sebastian
- --
Sebastian Gabmeyer
Business Informatics Group (BIG)
Vienna University of Technology

http://www.big.tuwien.ac.at/staff/sgabmeyer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJUM7ThAAoJELSN8YoN2kNZ6m8H/3ITcLQHtfe1If6JwRZ7Jh8H
OM7cLr9NbzBS4VCp5zrj7iYMFC5NrLE8vDUIyRj5Jhe0QGuTd+dtLVd1kEcHzpcF
Nmeh1C09nG9jYkxbqJCvDdn6DceyrMHzV/U0/9xln80byaDqPlZ20bJTXpvqto7x
AKfLx/MFHUZsApKxJPutyZw1GZtOvbMYXWr3VOZv5/FOXbnO7eMED+CknT4/mELm
I5lfK8RjcexS+dXuERUVkKRTavofNxLvAHGVUWNuOIKfYRJ5+05ZS2LHuVf0n7dJ
/udVSUoTqArctF9g8C9fr+3dd8rjwmD7PlmrcOYhAOGQMZw+k+7zW13/elJk2V8=
=0rFE
-----END PGP SIGNATURE-----
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-dev

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

Back to the top