Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "VIATRA/Transformation/Transformation Language"

(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...)
 
m (Ujhelyiz.incquerylabs.com moved page VIATRA/Transformation Language to VIATRA/Transformation/Transformation Language: restructuring)
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
== 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 38:
 
**Unboxing similarly needed  
 
**Unboxing similarly needed  
 
**Ordering and concurrent modification?  
 
**Ordering and concurrent modification?  
**
+
**<br>
  
 
==== Event-driven mode  ====
 
==== Event-driven mode  ====
Line 53: Line 53:
 
**Something in-between
 
**Something in-between
  
=== Extensibility ===
+
=== 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 05:32, 18 April 2016

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

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)

Back to the top