Related Work - mn-mikke/Model-driven-Pretty-Printer-for-Xtext-Framework GitHub Wiki

This page discusses approaches to the concept of pretty-printing in other projects dealing with creating domain-specific languages. Since the pretty-printing concept is an only supportive and not main aspect of language development and many experimental projects allowing a user to create a DSL exist, greater projects with a nontrivial history should be chosen in order to be more probable that the pretty-printing concept would be realized in the project.

Graphical Domain-specific Languages

Textual domain-specific languages allows a user to textually express various models therefore they presents models to a user. But modeling projects such as GMP, MetaEdit+, Obeo Designer, Microsoft DSL Tools allow a user to create graphical DSLs. An instance created with this language kind may look like a digram, a table or an another graphical representation. So as a textual DSL has its grammar, which describes the language, a graphical DSL has also an own kind of specification. This kind of specification associates meta-model elements, relations between elements with graphical entities that subsequently form the final representation of a model. Although, syntax highlighting and code formatting as such do not make sense with this kind of DSLs, there are some analogies. Text of attributes of model elements such as element's name can be decorated by font configuration specified in a specification of graphical representation for a meta-model element. Further, a user can align elements of a graphical representation manually and he can align marked elements horizontally or vertically at once in some projects.

EMFText

The EMFText is an alternative to the Xtext project. It allows for defining textual DSLs and interconnect them with meta-models of the Eclipse Modeling Framework. Although, a principle of a language creation is similar to the Xtext framework, this project does not offer any possibility to create a code formatter for a developed language. This language only supports the concept of lexical highlighting, where formatting configuration are associated with token types directly in a grammar specification.

Meta Programming System

This project has been developed by the JetBrains company and it is better known under the acronym MPS. This project is a projection editor, which it a little conceptually differs from the couple Xtext and EMF. The [EMF]((http://www.eclipse.org/modeling/emf/) allows a user to define models by creating meta-models and further transform them among themselves and generate them into code with assistance of another instruments. The Xtext framework subsequently allows a user to get given models from textual DSLs. Whereas the MPS exploits a definition of abstract syntax tree instead of a meta-model definition. This kind of AST is free from concrete syntax elements such as keywords, concrete textual tokens, etc. It essentially represents a abstract tree of logical nodes, which can be imagined as nonterminals. The instance of this kind of AST can be created and edited by a projection. It means that the AST is projected into a textual representation that can be modified by an editor, which does not make operations over the projected text but directly over the AST. The textual representation serves only as a virtual appearance of AST. The MPS will be able to project the AST into a graphical representation in the near future.

The question is how the MPS defines a projection of the AST into a textual representation and therefore the appearance of textual representation. It solves this requirement so that a developer has to define a editor for each kind of node contained in AST. The editor definition contains an appearance temple, which is essentially a box model. These box models exploits the horizontal, vertical and indenting operator which have no parameters because spacing is represented by special sub-boxes of an usage of a operator. Further, the box models do not contains any usage of a highlight operator because the editor for a box model allows a user to markup an individual elements of a given box model with a font configuration that is subsequently used for a corresponding textual representation of a element. The concept of syntax highlighting is realized in this way. On the contrary, the concept of code formatting by itself are missing because the project textual representation always satisfies templates of node editor and a user has no chance how to break a formatting. It is a consequence that the textual representation do not exist physically in the form of text.