Difference between revisions of "VIATRA/DeveloperDocumentation/Viatra2.0Brainstorming"

Revision as of 09:35, 3 November 2017

Viatra 2.0 Design Docs and Brainstorming, Fall 2017

Overview

Minimum dependencies

• Java 8
• Eclipse Mars
• Xtext 2.12
• Guava 21
• Eclipse Collections 9

Components to keep or graduate:

• Component upgrade plan

Main points to address

• Scoping and imports in VQL (breaking backward compatibility on query definitions)
• Minimum dependency updates (see above)
• Remove all deprecated API
• Consider using runtime exceptions instead of checked exceptions
• See list of issues in 2.0.0M1

Top priority until March 2018

• Runtime API breaks
• VQL2 language

Language design changes

• Add file-level element that can receive annotations
• Rethink public/private patterns
  • Let runtime know what is important for `Release` performance
  • Important for incremental engines: know what must be maintained, what can be flattened
• Compositional sources of base relations (scopes)
  • Better support for non-EMF scopes
  • Better support for user-supplied relations, magic sets, traceability, etc.
  • Must be mixable as freely as possible
• Minor syntactic sugar
  • graph-like mnemonic for unary and binary base relations
  • neg {local pattern}
  • neg BareType(notWrappedInHelperPattern)

Runtime design changes

• API debt
  • Remove all deprecated API
  • Consider using runtime exceptions instead of checked exceptions
• Compositional scopes to support associated language goal
• User-supplied relations
  • VQ Engine owner shall be able to provide (through an easy API) the contents of custom relations that the query definitions can rely on
    • API1 to provide custom relations that realize the relevant IQMC, IQRC methods, including index lookup and notifications
    • API2 where index lookups are taken care of, contents and notifications are still provided by the user
    • API3 where these relations are implemented e.g. as a set (with indexer lookups, notifications, etc.), the user can call manipulation operations
  • Must be possible to add a posteriori to any other scope (e.g. EMF), see also compositional scopes
• Do we need surrogate values in the EMF base index?
• Rethink matcher API
  • In case of surrogates, remove types from API
  • Can Matches also be Tuples, or at least backed by them? Try to reduce (persistent and transient) duplication.
• Distributed processing extensions
  •  ???