Design and implement support for NACs

eMoflon / emoflon-ibex

Shared, eMoflon-specific component for incremental unidirectional and bidirectional graph transformations

GNU General Public License v3.0

13 stars 4 forks source link

Design and implement support for NACs #66

Closed erhanleblebici closed 7 years ago

erhanleblebici commented 7 years ago

emoflon.ibex currently doesn't support NACs. There are some open decisions before starting the implementation work:

Do we only support NACs with one node/edge as it was the case before? Or we support complex NACs that go beyond single nodes/edges? Do we plan to support nested NACs?
If we support complex (and perhaps nested NACs): How should the textual syntax look like? What about backward compatibility?

My impression so far: it won't make any difference for pattern matcher between complex and one node/edge NACs (both are realized via negative pattern invocations). I'm rather concerned about the design and the backward compatibility of textual syntax if we allow complex NACs. Nested NACs seem to me too ambitious for the first version, but clearly feasible with regard to pattern matching.

erhanleblebici commented 7 years ago

After a discussion with @anthonyanjorin, following decisions seem to be plausible:

Short term: we support only one node/edge NACs so that we at least can reuse existing TGGs for testing. (Then this issue will be closed)
Long term: we provide a constraint language and a static analysis for "generating" NACs (and PACs?) that enforce the constraints. Constraint enforcing NACs/PACs are the only ones we want to support anyway. (This will be a completely new issue)

anthonyanjorin commented 7 years ago

Not sure if we want this. We have to migrate existing tggs manually anyway. We could delete all NACs in the process. I have the feeling that almost all NACs currently in usage can be generated automatically by analysing upper bounds of multiplicities.

anthonyanjorin commented 7 years ago

What do you think @erhanleblebici? It shouldn't be such a big deal to automatically generate target NACs from upper bounds of multiplicities. This module can then be extended in the future (using Henshin or whatever for the [constraints=>application conditions] transformation.

As this decision influences our pattern network, I don't want to wait too long before integrating it (especially regarding the current work on refinements).