Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "VIATRA/Transformation/Transformation Language"
< VIATRA | Transformation
(New page: == Transformation language over EMF Models == Design draft page This page describes a new language for describing models transformation, that builds on the experiences with the origina...) |
|||
(8 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
+ | {{VIATRA}} | ||
== Transformation language over EMF Models == | == Transformation language over EMF Models == | ||
− | Design draft page | + | == Design draft page == |
This page describes a new language for describing models transformation, that builds on the experiences with the original [[VIATRA2/Transformation Language|VIATRA2 Transformation Control Language (VTCL)]] and its spinoff, the pattern-based query language of [[EMFIncQuery|EMF-IncQuery]]. It builds on the same concepts as the VTCL language, and directly re-uses the IncQuery pattern language for pattern definitions. | This page describes a new language for describing models transformation, that builds on the experiences with the original [[VIATRA2/Transformation Language|VIATRA2 Transformation Control Language (VTCL)]] and its spinoff, the pattern-based query language of [[EMFIncQuery|EMF-IncQuery]]. It builds on the same concepts as the VTCL language, and directly re-uses the IncQuery pattern language for pattern definitions. | ||
Line 38: | Line 39: | ||
**Unboxing similarly needed | **Unboxing similarly needed | ||
**Ordering and concurrent modification? | **Ordering and concurrent modification? | ||
− | ** | + | **<br> |
==== Event-driven mode ==== | ==== Event-driven mode ==== | ||
Line 53: | Line 54: | ||
**Something in-between | **Something in-between | ||
− | === | + | === The imperative language === |
− | *Changable control flow (e.g. different interpreter/generated code strategies) | + | *essentially based on XBase |
− | *Insertion of custom Java code (at least as black box rules) | + | *interaction with IncQuery and other features of our own |
+ | **maybe we do not even need special syntax for rule invocation, etc.., if we manage to make the API itself simple enough | ||
+ | **one possible simplification: the engine should be already available in the context of this imperative code, so it should be possible to omit | ||
+ | **similarly, try to make IQBase features concisely available | ||
+ | *EMF-specific syntactic sugar for model manipulation (reusable in non-imperative parts?) | ||
+ | **concise access to EPackage elements if they are imported (we need EPackage imports for the query definition part anyway) | ||
+ | **concise object instantiation | ||
+ | ***idiom for creating object and initializing fields | ||
+ | ***idiom for "create this new object and put it into this ''containment'' reference list so that it becomes part of the model immediately" | ||
+ | ***these two should be combinable... ideally we should have something like EMF subtree literals (see also VTML) | ||
+ | **make sure that putting elements into containment lists will translate as NavigationHelper.cheapMoveTo() for the performance benefit | ||
+ | **see if e.g. Epsilon Object Language has good ideas | ||
+ | |||
+ | === Extensibility === | ||
+ | |||
+ | *Changable control flow (e.g. different interpreter/generated code strategies) | ||
+ | *Insertion of custom Java code (at least as black box rules) | ||
*Other domain support (VPM, triple stores) | *Other domain support (VPM, triple stores) |
Latest revision as of 09:18, 28 March 2024
Contents
Transformation language over EMF Models
Design draft page
This page describes a new language for describing models transformation, that builds on the experiences with the original VIATRA2 Transformation Control Language (VTCL) and its spinoff, the pattern-based query language of EMF-IncQuery. It builds on the same concepts as the VTCL language, and directly re-uses the IncQuery pattern language for pattern definitions.
History
Main VTCL language elements
- pattern: for defining constraints and conditions; multiple possibly pattern matchers available
- gtrule: graph transformation rule describe elementary model manipulation steps, either as two graph patterns or a graph pattern and some imperative control (usually add/remove/update operations!)
- asmrule: imperative control structures
- asm function: globally available maps keyed by tuples
- asm function: globally available maps keyed by tuples
New ideas not entirely supported by the existing language
- Alternative traversal methods, e.g. probabilistic simulation or design space exploration
- Worked around by extending/replacing the interpreter
- Native EMF support
- Importer/exporter was used
- High-level support for event-driven transformations
- Preliminary support was introduced via triggers
Design ideas
Graph pattern matching
- Graph pattern syntax and semantics re-used from EMF-IncQuery
Batch transformations
- boolean operation -> check whether at least one match exists
- Select one match for processing
- Unboxing to single variables needed -> look for compatibility with EMFIncQuery Match processors
- Which one to return: unspecified or random or first/last/nth via some ordering
- Select all matches for processing
- Unboxing similarly needed
- Ordering and concurrent modification?
Event-driven mode
- Defining what to do when a match
- appears
- disappears
- is updated
- Control elements to wait for some conditions?
- Reuse of EMF-IncQuery EVM
- Question: how to register event-driven rules, possible strategies
- Fully event-driven transformation - every rule registered
- Imperative style: only manual registration
- Something in-between
The imperative language
- essentially based on XBase
- interaction with IncQuery and other features of our own
- maybe we do not even need special syntax for rule invocation, etc.., if we manage to make the API itself simple enough
- one possible simplification: the engine should be already available in the context of this imperative code, so it should be possible to omit
- similarly, try to make IQBase features concisely available
- EMF-specific syntactic sugar for model manipulation (reusable in non-imperative parts?)
- concise access to EPackage elements if they are imported (we need EPackage imports for the query definition part anyway)
- concise object instantiation
- idiom for creating object and initializing fields
- idiom for "create this new object and put it into this containment reference list so that it becomes part of the model immediately"
- these two should be combinable... ideally we should have something like EMF subtree literals (see also VTML)
- make sure that putting elements into containment lists will translate as NavigationHelper.cheapMoveTo() for the performance benefit
- see if e.g. Epsilon Object Language has good ideas
Extensibility
- Changable control flow (e.g. different interpreter/generated code strategies)
- Insertion of custom Java code (at least as black box rules)
- Other domain support (VPM, triple stores)