MOSL SDM language and feature discussion

[RolandKluge]

From @gervarro on June 17, 2016 23:33

Here are my first set of comments to @anthonyanjorin @erhanleblebici @RolandKluge regarding the textual SDM language

• I think that the control flow language (Operation) could probably be part of / integrated into an ecore textual language that specifies the static structure. I find the op List.getLastNode() notation (as a standalone method specification outside the List class) rather counter-intuitive to specify that there exists a getLastMethod() in the List class.
• I find a single variable in the return statement return last significantly better than the f@getFirstAndLast notation.
• The explicit type declaration might be unnecessary in case of pattern invocations as this information might be derivable from the pattern declaration. In case of method/operation invocations (e.g., last : Node = this.getLastNode()) the default type can also be derived from the return type of the method, however, enforcing a type cast definitely necessitates an explicit type declaration.

I would define patterns as follows:

pattern getFirstAndLast(list : List, first : Node, last : Node) {
   nodes(list, first);
   nodes(list, last);
   neg nac1(first);
   neg nac2(last);
}

pattern nac1(first : Node) {
   local noPrev : Node;
   previous(first, noPrev);
}

pattern nac2(last : Node) {
   local noNext : Node;
   next(last, noNext);
}

Explanation:

• The ! noPrev : Node notation hinders the specification of complex NAC patterns (i.e., the concept that Fred wanted to build into the SDM language).
• I would keep the core pattern language as simple as in the above example, however, I could imagine some domain-specific extensions for the GT rule language.
  • nodes(list, first) could alternatively be specified as list - nodes -> first, however, this has already an implicit meaning that nodes is an edge that connects list to first, which is OK if the pattern language specifies graph structures, but I would like to keep the core pattern language as generic as possible.
  • I could imagine anonymous/unnamed/embedded internal patterns for NACs, however, the invocation of a first-class/named pattern should definitely remain part of the core pattern language.

When the pattern language already exists, I would extend it to a GT rule language. Markers ++ and -- would only occur in the GT rule language but not in the pattern language. My key requirement is that the (core) pattern language must be usable without the GT and the control flow languages.

I think that the ++ and -- markers are OK in a textual GT rule specification, however, note that the GT rules have to be mapped to several Democles patterns in the internal process.

Copied from original issue: eMoflon/emoflon#747

[RolandKluge]

From @anthonyanjorin on June 18, 2016 6:25

I've thought a while about having an ecore textual syntax and I'm now against it:

• we would have extra work and there already exists acceptable, standard editors from EMF
• there is already Xcore if someone really wants to specify class diagrams textually
• as we have to deal with external ecores anyway, we would have the technical problem of always taking care of two possible references in the syntax: to an ecore element from an existing ecore, or to an "ecore" element from our own syntax (which would not have been transformed to ecore yet)
• the alternative would be having to transform any ecore to the textual syntax (this is how we are using EA right now) should really be avoided
• users would have the expectation to be able to specify complete ecore, and a look at xcore shows that this is actually quite a lot (let's spend our time and resources on what we actually want to do)

[RolandKluge]

From @anthonyanjorin on June 18, 2016 7:7

Well I thought the @ to refer to variables in expressions would be a nice touch :)

As we, however, must have a normal return statement anyway, we might as well use it for all cases.

[RolandKluge]

From @anthonyanjorin on June 18, 2016 7:12

Good point with complex NACs, as simple NACs are used quite often it wouldn't be bad to support both (as Greg already suggests): so ! noPrev : Node as well as ! complexNACPattern

[RolandKluge]

From @anthonyanjorin on June 18, 2016 7:14

From the end user's point of view, why do we need to "separate" the languages? We can transform specifications to any number of disjunct metamodels but for the end user everything is the same language (the core pattern language is just a subset of all language features). Am I missing something here?

Xtext's support is not that amazing for modular languages, I'm not sure how much we should try to separate the actual technical language specifications.

[RolandKluge]

From @anthonyanjorin on June 18, 2016 7:27

I have to admit that I don't yet understand how pattern invocation works. This is sort of some kind of control flow in patterns, and how is recursion handled? This is completely new language feature that I'll have to get used to and can't really say much about

[RolandKluge]

From @anthonyanjorin on June 18, 2016 7:30

I've gotten used to the tgg pattern textual syntax and actually quite like the way the pattern is organised into object variables (top level) and outgoing link variables in each object variable scope (this also works nicely with code completion). If no one else wants to have SDM patterns this way then we can forget it. We could also support it and allow for the more general syntax Greg suggests. One decision would be if one must use the explicit syntax for graph patterns or if one can choose.

[RolandKluge]

From @gervarro on June 18, 2016 23:42

I've thought a while about having an ecore textual syntax and I'm now against it:

I know that this requires additional efforts. I think that this would be the nicest solution, but you are right that this is not a top priority task, so we can forget about it for a while. Btw. cannot we integrate our SDM/TGG textual language into Xcore in the same way as we integrated SDMs into Ecore?

Well I thought the @ to refer to variables in expressions would be a nice touch :)

I might have misinterpreted something. In your example, @ referred to a variable in a GT rule application, and not in an expression.

From the end user's point of view, why do we need to "separate" the languages? We can transform specifications to any number of disjunct metamodels but for the end user everything is the same language (the core pattern language is just a subset of all language features). Am I missing something here?

There are many cases (e.g., declarative validation patterns for Democles/SDM/TGG specifications), when only declarative patterns are aimed to be defined (without SDMs, without TGGs). The role of the core pattern language would be to enable the direct specification of Democles patterns exactly on the abstraction level that is supported by the pattern matcher. Some language extensions (e.g., simple NACs like! node : Node) are simply non-existing on this level. As far as I know, there is a concept of non-terminal subclassing in Xtext, which could be used to separate the core pattern language from the rest.

One decision would be if one must use the explicit syntax for graph patterns or if one can choose.

I would like to open up further possibilities for the pattern matcher, and restricting the core pattern language only to 'graph' patterns would be against this step.

I have to admit that I don't yet understand how pattern invocation works. This is sort of some kind of control flow in patterns, and how is recursion handled?

Pattern invocation is a way to declaratively specify patterns of arbitrary size. http://dx.doi.org/10.1007/978-3-540-89020-1_31

Summary: I would like to have a core pattern language that can be directly mapped to Democles patterns. I can support any kinds of extensions (simple NACs, ...) or alternative solutions (explicit syntax for graph patterns, ...), if these do not affect the core pattern language.

[RolandKluge]

From @gervarro on June 19, 2016 8:39

Just one additional comment. I think that it is practical to define the SDM textual syntax for the internal ControlFlow metamodel and not for the current SDM metamodel, as in this case the ugly and complex control flow validation, which turns the spaghetti control flow into a structured Java-like control flow, could be completely eliminated. However, if the textual syntax is mapped to the internal metamodel, then the closer they are in their structure, the easier it is to implement the mapping/synchronization. The internal metamodel invokes Democles patterns, which means that the extensions (e.g., the simple NAC notation ! node : Node) and the alternative solutions require additional implementation efforts and result in a more complex mapping in the end.

[RolandKluge]

The discussion has become quite long now and we are discussing many topics.

I try to give my opinion in a short way for each topic: ---NACs

• Complex NACs are definitely desirable
• I always liked the pattern-invocation-paradigm because it is easy to learn (similar to method invocations). Actually, you also invoke the pattern inside the control flow in a very similar way as you invoke NAC (or even PAC) patterns.
• I would prefer 'neg' as keyword for specifying negative pattern invocations.

---Support for meta-modeling?

• I am against creating yet another Ecore modeling language if we are able to leverage relatively well-engineered existing solutions.
• However, it should be easy enough for the user to specify a simple meta-model (e.g., our handbook example) without creating 2,3,... projects!

---Link variables

• I like the intuitive arrow-style notation (e.g., --nodes-->).
• Still, I see Greg's point that it is tailored to Ecore meta-models.
• To this end, I would not embed the link variables in object variables. Instead, e.g.,
  • list : List; first : Node; last : Node
  • list -nodes-> first ; list -nodes-> last
• When engineering MOSL-SDM, we should keep in mind that patterns basically consist of variables and constraints. Period. This is also the way, it is modeled in the 'backend'.

---Pattern vs. Rule

• In the presence of '++' and '--' I would even say that our current patterns are actually rules and we should name them like this!
  • Btw. I would keep the '++' and '--' syntax if possible. It is concise and easy to understand.

---using and import

• I like the separation of import and using

---op's

• Why not write 'operation'?
• I don't mind the notation for specifying the containing class.
  • An alternative proposal with less redundancy: class List { op getLastNode(); op getFirstNode(); }

---AT - Referencing match variables

• For me, the AT-notation is counter-intuitive.
• I like Greg's proposal of specifying local variables. This is again relatively similar to the way it is handled in the backend.
  • One thing that I would Really appreciate is if we would treat matches as first-class citizens.
  • How can we represent lists of matches? ("any"/"all" keyword?)
  • Here, it could make sense to introduce an operator for addressing variables:
  • m = getFirstAndLast(this, _, ); return m[0 / 1 / 2]

[RolandKluge]

Assigned @gervarro since he is the MOSL-SDM lead developer.

[RolandKluge]

Closing this issue do. Results of the discussion are documented here:

https://github.com/eMoflon/emoflon-docu/wiki/Discussion-on-MOSL-GT