• Page
• Discussion
• View source
• History

From Eclipsepedia

You do not have permission to do that, for the following reason:

You can view and copy the source of this page:

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 [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: * 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]])]] ==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. [[Category:Modeling]]

Return to TMF/LongRunPlans.