Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [henshin-user] NestedConditions

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/

Back to the top