TMF/LongRunPlans

Here we can discuss our proposals and requests for a single Textual Modeling Framework in future. For now, TMF hosts two sub-projects: Xtext and TCS.

TMF architecture and implementation are defined according to the experience gained in the development of these two frameworks.

Expected TMF Features

This section proposes a list of features to be discussed:

• A Domain-Specific Language (DSL) for textual concrete syntax definition. The abstract syntax of languages is defined as a metamodel (e.g., in EMF Ecore, in KM3). The TMF DSL for textual concrete syntax definition will provide means to specify how each metamodel concept is represented textually, similarly to what TCS currently does. This DSL should support:
  • Definition of non context-free elements (e.g., symbol table used for cross-references).
  • Declarative definition of operators, and automatic generation of specific grammar rules to handle them.
• Support for definition of TMF textual syntaxes from a grammar. In this case, both a metamodel (abstract syntax), and a TMF textual syntax model (concrete syntax) may be generated from the grammar. This mechanism will enable reuse of existing grammars, as well as accommodate developers with a grammarware background.
  • TBD: we may not want to force a one way translation from the grammar, but also support grammar-based development (e.g., like in xText). However, supporting this is likely to be more expensive than requiring a transition to metamodel + TMF textual syntax model.
• Parsing and pretty-printing. Using the syntax specification, TMF will provide:
  • parsing (or injection) to translate textual programs into models (e.g., in EMF).
  • pretty-printing (or extraction) to translate models into program.
• Syntax-aware editors. Using the syntax specification of a given language, TMF will provide a lightweight (e.g., interpretative) language-specific editor with: syntax highlighting, text hovers, hyperlinks, an outline, etc. This editor may integrate with GMF to provide Graphical-Textual hybrid editors. This editor would be similar to:
  • the current TCS-based Textual Generic Editor (TGE), as illustrated in the screenshots of the TCS project page, and on the image
    

    TGE screenshot
    at the right of this paragraph.
  • the xText editor.
• Support for constraints checking in the TMF language-specific editor.
• Support for language extension. Extending a language will consist of:
  • extending its metamodel (i.e., abstract syntax), which is going to be based on mechanisms provided by metametamodels (e.g., EMF Ecore inter-metamodel references, KM3 metamodel extension).
  • extending its concrete syntax, which is going to be based on specific support for extension in the TMF textual concrete syntax DSL.
• A library of TMF-defined languages. This library will illustrate TMF usage, and may serve as a collection of examples, but also as a starting point (e.g., by extending the languages it provides). An example of such a library is the TCS zoo.

Flexible Implementation Requirements

This section contains a list of requirements regarding the implementation of TMF, and its (relative) independence with respect to specific tools:

• Support for several parsing back-ends. Instead of targeting a single parser generator, TMF will have a flexible architecture (see Figure 1) enabling support for parser generators like: ANTLR, LPG. This can be achieved using a mechanism such as the ParserWrapper class of TCS.
• Support for several editing back-ends. The TMF architecture will accommodate several kinds of language-specific editors: IMP (formerly known as SAFARI), the lightweight TMF-specific editors, etc.
• Support for several kinds of constraints checking engines.
• Support for several modeling framework. Although EMF is the primary modeling framework on which TMF will be based, some features (such as parsing, and pretty printing) should work with other frameworks (including pure Java ASTs?).
  • API-independence may be achieved using a mechanism such as the ModelHandler interface of TCS.
  • Metametamodel-independence may be achieved using a metametamodel pivot such as the Kernel MetaMetaModel (KM3).

Figure 1. Architecture of the TMF grammar generator (zipped Visio source)

Other Considerations

This section contains a list of requirements that do not fit in the previous sections:

• A model-based implementation. As far as possible, TMF implementation will use Model Engineering techniques: model-to-model ([M2M]) transformations to create grammars or editor configurations from TMF definitions (i.e., similarly to what TCS and TGE currently do), Model to Text (M2T) for Java code or documentation generation, etc.
  • This requirement will show our confidence in Model Engineering techniques.
  • To achieve a model-based implementation, the syntax of the TMF textual concrete syntax definition TCS will have to be bootstrapped. In a first step, it will be defined using either TCS or xText.