|(5 intermediate revisions by 2 users not shown)|
|−|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 [http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/xtext_reference.html xText] and [[TCS]] [[GMT]] components. |+|
Textual Modeling Framework . implementation of .
| || |
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. This DSL should support: |+|
[http://www.eclipse.org/] of the , but is .
|−|** 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 [http://www.eclipse.org/ gmt/oaw/doc/4.2/html/contents/xtext_reference.html 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 [http://www.eclipse.org/ gmt/tcs TCS project page] , and on the image [[Image:LOTOS-TGE.png|thumb|TGE screenshot]] at the right of this paragraph. |+|
|−|** the [http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/xtext_tutorial.html#xtext_tutorial_fill_model 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|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: |+|
with such as , , of . for , features a of . be .
|−|* 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: [http://www.antlr.org/ ANTLR], [http://sourceforge.net/projects/lpg/ LPG]. This can be achieved using a mechanism such as the [http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt/org.eclipse.gmt.tcs/plugins/org.eclipse.gmt.tcs.injector/src/org/eclipse/gmt/tcs/injector/wrappers/ParserWrapper.java?view=markup ParserWrapper] class of [[TCS]]. |+|
|−|* Support for several editing back-ends. The TMF architecture will accommodate several kinds of language-specific editors: [http://www.eclipse.org/proposals/imp/ 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 [http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt/org.eclipse.gmt.tcs/plugins/org.eclipse.gmt.tcs.injector/src/org/eclipse/gmt/tcs/injector/ModelHandler.java?view=markup ModelHandler] interface of [[TCS]]. |+|
|−|** Metametamodel-independence may be achieved using a metametamodel pivot such as the [[KM3|Kernel MetaMetaModel (KM3)]]. |+|
| || |
|−|[[Image:TMF_ArchitectureV1.png|frame|center|Figure 1. Architecture of the TMF grammar generator ([[Media:TMF_ArchitectureV1.zip|zipped Visio source]])]] |+|
that will .
|−|==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 [ http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt/org.eclipse.gmt.tcs/dsls/TCS/Compiler/TCS2ANTLR.atl?view=markup 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. |+|
The Textual Modeling Framework (TMF) is an umbrella project under the Eclipse Modeling Project (EMP). It hosts two different framework for implementation of textual syntax for EMF models (aka Ecore models).
Xtext is a framework for development of programming languages and domain specific languages (DSLs). Just describe your very own DSL using Xtext's simple EBNF grammar language and the generator will create a parser, an AST-meta model (implemented in EMF) as well as a full-featured Eclipse text editor from that.
The Framework integrates with technology from Eclipse Modeling such as EMF, GMF, M2T and parts of EMFT. Development with Xtext is optimized for short turn-arounds, so that adding new features to an existing DSL is a matter of minutes. Still sophisticated programming languages can be implemented.
It is intended that at some point there will be only one framework instead of two.
Requirements and thoughts can be discussed here