|
Hi Stefan,
thanks for looking into this, these are some valuable insights.
Point 1 shows that it's been a while since I tried this out
myself ;-) I can reproduce your observation: The "border elements
only" NAC is interpreted with a "full LHS replicated" semantics,
that is, objects already bound by the LHS are not considered for
matching the NAC.
Points 2 and 3 clarify that full LHS replication is indeed the
default behavior in the graphical editor, but that there are some
bugs related to synchronization, the graphical editor's number-one
source of errors. Thanks also for offering to have your student
look into this.
To wrap up, it seems like the interpreter (in contrast to my
previous statement) indeed uses the standard semantics, and, to
achieve that, shows some tolerance w.r.t. incomplete
specifications of the morphism. An alternative semantics with
actual partial morphisms might be desirable for some cases, but
won't become our most urgent feature request, as our lives are
interesting enough.
Best regards,
Daniel
On 12/20/2019 10:10 AM, S. John wrote:
Three
things to note here:
1. In theory I would have said yes. In practice, however, I don't
observe a difference running a rule with the whole replication vs.
replicating only the border element (see attached rules). Did I
miss something?
2. I don't observe the partial mapping being the standard
behavior. For me it usually maps the Whole LHS to the NAC, but:
3. There seems to be a flaw in the graphical editor where the
order in which you create the forbid and preserve parts of a rule
influences how many elements are replicated and mapped.
Preserve elements which are added to a rule after a NAC has been
created (by changing the action of a node to forbid) will not be
replicated to that NAC. If you want to add existing preserve nodes
to a NAC a workaround can be to change the desired forbid nodes to
preserve and back to forbid again.
In the past, I already observed strange behavior in not being able
to create edges between forbid and preserve nodes sometimes but
didn't search for the reason.
Now that I know the problem, I will assign my
Henshin-Bugfix-Student to it. No guarantees on how long this will
take, though. ;)
Stefan
On 19.12.2019 15:06, Zschaler, Steffen wrote:
Just to make sure I understand this
correctly:
* When only the border elements are replicated in the NAC
(here: the
:A node), the NAC looks like this:
* B -> A (where A has a mapping from the LHS)
*
Wouldn’t that mean the rule can simply never be matched (because
there would, by definition always be a B to be matched for the
NAC)?
Steffen
Dr. rer. nat. Steffen Zschaler AHEA
Senior Lecturer
King's College London
Department of Informatics
Visiting Scientist
The Francis Crick Institute
Email szschaler@xxxxxxx
Phone +44 (020) 7848 1513
WWW www.steffen-zschaler.de
*From:*henshin-user-bounces@xxxxxxxxxxx
<henshin-user-bounces@xxxxxxxxxxx> *On Behalf Of *Daniel
Strüber
*Sent:* 19 December 2019 13:26
*To:* henshin-user@xxxxxxxxxxx
*Subject:* Re: [henshin-user] NestedConditions
Consider a rule (using the integrated syntax:)
[forbid :B] ---> [preserve :A] <---- [preserve :B]
<----- [create :C]
When only the border elements are replicated in the NAC (here:
the :A node), the NAC looks like this:
B -> A (where A has a mapping from the LHS)
When the full LHS is replicated, the NAC looks like this:
B -> A <- B (where A, the right-hand B, and their
common edge have mappings from the LHS)
Using the first NAC, the forbid node can be matched to all :B
objects from the input model, including one which was bound to
the preserve :B node while matching the LHS.
Using the second NAC, the forbid node cannot be matched to a :B
object which was already bound by LHS :B node.
Best regards,
Daniel
On 12/19/2019 2:15 PM, Zschaler, Steffen wrote:
Thanks, Daniel. You seem to imply that there is a semantic
difference between the three forms. Could you explain?
Thanks,
Steffen
Dr. rer. nat. Steffen Zschaler AHEA
Senior Lecturer
King's College London
Department of Informatics
Visiting Scientist
The Francis Crick Institute
Email szschaler@xxxxxxx <mailto:szschaler@xxxxxxx>
Phone +44 (020) 7848 1513
WWW www.steffen-zschaler.de
<https://eur03.safelinks.protection.outlook.com/?url="">
*From:*henshin-user-bounces@xxxxxxxxxxx
<mailto:henshin-user-bounces@xxxxxxxxxxx>
<henshin-user-bounces@xxxxxxxxxxx>
<mailto:henshin-user-bounces@xxxxxxxxxxx> *On Behalf
Of *Daniel Strüber
*Sent:* 19 December 2019 13:13
*To:* henshin-user@xxxxxxxxxxx
<mailto:henshin-user@xxxxxxxxxxx>
*Subject:* Re: [henshin-user] NestedConditions
Hi Steffen,
Henshin allows the morphism between the host graph and the
application condition graph to be a partial morphism.
Consequently,
all three cases you mention (only nodes replicated, only
border
nodes replicated, full LHS replicated) would specify
different
application conditions for the same rule.
While this design decision has its awkward sides (especially
the
representation in the graphical editor), I encountered some
situations before where it was desirable, as it allowed to
precisely
specify an intended behavior.
I'm actually surprised by the fact that the graphical editor
defaults to the "node only" case -- I would have expected
"full LHS
replicated" as the default. However, in most cases, the
resulting
behavior will be identical. The only exceptions seem to
arise in the
(exceptionally rare) case where there are multiple
references of the
same type between the same two objects.
Best regards,
Daniel
On 12/19/2019 11:32 AM, Zschaler, Steffen wrote:
Hi,
A rather technical question about *NestedCondition*s and
their
/representation/ in a .henshin file. Do tell me to take
this
somewhere else if that would be more appropriate.
I understand the theory behind application conditions:
the
condition is a graph and a morphism into this graph from
a host
graph. That is represented in Henshin by the ability to
add a
“formula” to a graph, where this formula can be a
*NestedCondition*, which itself again contains a graph
and a set
of mapping. The containing graph is the host graph, the
graph in
the *NestedCondition* is the application-condition
graph, and
the mappings capture the morphism. So far so clear.
Except that’s not how it seems to work in practice: if
you look
at the attached file, produced by the standard graphical
editor,
you will see that only the /nodes/ from the host graph
have been
replicated in the application-condition, but the /edges/
haven’t. In other examples, I have seen cases where only
the
border nodes had been replicated. In any case, the
mappings
clearly aren’t a morphism as they do not fully cover the
host graph.
Are all of these formats indeed acceptable? If so, is
there a
regularised format that is used inside Henshin and, if
so, can
this be reused outside of Henshin? Alternatively, are
there
minimum expectations on how an application condition
should be
encoded in a .henshin file? Is any of this documented
anywhere?
Should it be?
Thanks,
Steffen
Dr. rer. nat. Steffen Zschaler AHEA
Senior Lecturer
King's College London
Department of Informatics
Visiting Scientist
The Francis Crick Institute
Email szschaler@xxxxxxx <mailto:szschaler@xxxxxxx>
Phone +44 (020) 7848 1513
WWW www.steffen-zschaler.de
<https://eur03.safelinks.protection.outlook.com/?url="">
_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
<mailto:henshin-user@xxxxxxxxxxx>
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/henshin-user
<https://eur03.safelinks.protection.outlook.com/?url="">
--
Dr. Daniel Strüber
Postdoctoral Researcher
Department of Computer Science and Engineering
Chalmers | University of Gothenburg, Sweden
http://danielstrueber.de/
<https://eur03.safelinks.protection.outlook.com/?url="">
_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
<mailto:henshin-user@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/henshin-user
<https://eur03.safelinks.protection.outlook.com/?url="">
--
Dr. Daniel Strüber
Postdoctoral Researcher
Department of Computer Science and Engineering
Chalmers | University of Gothenburg, Sweden
http://danielstrueber.de/
<https://eur03.safelinks.protection.outlook.com/?url="">
_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.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://www.eclipse.org/mailman/listinfo/henshin-user
--
Dr. Daniel Strüber
Postdoctoral Researcher
Department of Computer Science and Engineering
Chalmers | University of Gothenburg, Sweden
http://danielstrueber.de/
|
