TMF

Here we can discuss our proposals and requests for a Textual Modeling Framework. TMF architecture and implementation are defined according to the experience gained in the development of the xText and TCS GMT components.

Expected TMF Features

This section contains a list of expected features to be supported by TMF:

• 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.
• 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 would be similar to the current TCS-based Textual Generic Editor (TGE), as illustrated in the screenshots of the TCS project page, and similar to 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).

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.

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