VIATRA/Transformation/Transformation Language

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)