To be able to build e ective DSLs, these DSLs must not just use language concepts that are aligned with their respective domain, but also use notations that correspond closely to established domain notations { and those are often not purely textual or graphical. The underlying language workbench must support these notations, and combining di erent notations in a single editor must be supported as well in order to support the coherent de nitions of systems that use several DSLs. In this paper we provide an overview over the notations supported by JetBrains MPS. MPS is a language workbench that uses a projectional editor, which, by its very nature, can deal with many di erent notational styles, including text, prose, math tables and graphics. The various supported notations are illustrated with examples from real-world systems.
The GEMOC 2014 workshop description states: To cope with complexity, modern software-intensive systems are often split in di erent concerns, which serve diverse stakeholder groups and thus must address a variety of stakeholder concerns. These di erent concerns are often associated with specialized description languages and technologies, which are based on concern-speci c problems and solution concepts. In particular, these di erent concerns also require di erent notations. Ideally, these notations are closely aligned with existing domain-speci c notations used by the stakeholders. However, such existing notations are not necessarily just text: they use forms, diagrams, mathematical symbols, a mix of prose and structure or combinations of those. Representing such diverse notations faithfully requires a high degree of exibility in the kinds of editors that can be built with the language workbench used to create the languages.
Projectional editing (see Section 2) allows creating editors that can use a wide
variety of notations, including the ones mentioned above. In particular, it can also
mix these notations seamlessly, leading to a more faithful representation of existing
domain languages in tools. JetBrains MPS is one of the leading projectional
editors, and this paper describes its capabilities in terms of notational exibility.
Contribution This paper provides an overview over the notational styles
currently supported by MPS. For each style we discuss why it is useful, where it
is being used as well as some details about how to de ne the respective editors.
Availability of the Code JetBrains MPS is open source software available
from http://jetbrains.com/mps. Also, those editor facilities that are separate
plugins to MPS are open source software and their repositories are indicated in
each case. The examples shown in this paper are mostly based on mbeddr [
Structure In the next section we provide a brief overview over MPS' projectional editor and show brie y how to implement regular text editors. Section 3 introduces the fundamental notations supported by MPS and Section 4 discusses other useful features of the MPS editor. We conclude the paper with a brief discussion and summary in Section 5. 2
What is Projectional Editing? In parser-based editors users type sequences of characters into a text bu er. The bu er is parsed to check whether the sequence of characters conforms to a grammar. The parser ultimately builds an abstract syntax tree (AST), which contains the relevant structure of the program, but omits syntactic details. Subsequent processing (linking, type checks, transformation) is based on the AST. Modern IDEs (re-)parse the concrete syntax while the user edits the code, continuously maintaining an up-to-date AST in the background that re ects the code in the editor's text bu er. However, even in this case, this AST is created by a parser-driven transformation from the source text.
A projectional editor does not rely on parsers. As a user edits a program, the AST is modi ed directly. Projection rules are used to create a representation of the AST with which the user interacts, and which re ects the resulting changes. No parser-based transformation from concrete to abstract syntax is involved. This approach is well-known from graphical editors: when editing a UML diagram, users do not draw pixels onto a canvas, and a \pixel parser" then creates the AST. Rather, the editor creates an instance of uml.Class when a user drops a class. A projection engine renders the class as a rectangle. As the user edits the program, program nodes are created as instances of language concepts. Programs are stored using a generic tree persistence format (such as XML).
The projectional approach can be generalized to work with any notation,
including textual. A code-completion menu lets users create instances based on
a text string entered in the editor called the alias. The aliases allowed in any
given location depend on the language de nition. Importantly, every next text
string is recognized as it is entered, so there is never any parsing of a sequence
of text strings. In contrast to parser-based editors, where disambiguation is
performed by the parser after a (potentially) complete program has been entered,
in projectional editors disambiguation is performed by the user as he selects
a concept from the code-completion menu. Once a node is created, it is never
ambiguous, irrespective of its syntax : every node points to its de ning concept.
Every program node has a unique ID, and references between program elements
are represented as references to the ID. These references are established during
program editing by directly selecting reference targets from the code-completion
menu; the references are persistent. This is in contrast to parser-based editors,
where a reference is expressed as a string in the source text, and a separate name
resolution phase resolves the target AST element after the text has been parsed.
Projectional editing has two advantages. First, it supports exible composition
of languages because the ambiguities associated with parsers cannot happen
in projectional editors. We do not discuss this aspect in this paper and refer
the reader to [
De ning a Simple Editor In order for the reader to better understand the
explanations in Sections 3 and 4, this section brie y introduces the MPS structure
and editor de nitions. MPS' meta model is similar to EMF Ecore [
Fig. 3 shows the de nition of the sum editor. It uses the new primitive LOOP
which can be used for everything that has a big symbol as well as things above,
below and right of the symbol. The particular symbol is de ned separately and
referenced from the editor de nition. The LOOP cell has three slots (lower, upper
and body) into which child nodes can be added. The Sum expression de nes
children upper, body and lower, which are mapped to these slots. These slots
can contain arbitrary editor cells, not just child collections: the lower slot contains
a collection that projects the name property, an equals sign and the lower child.
rendered as a table. Another example used in mbeddr [
Tables come in several avors. For example, a row-oriented table has a xed
set of columns and a variable list of rows. Users can add rows, but the columns
are prescribed by the language de nition. In contrast, the state machine shown
in Fig. 4 is a cell-oriented table: users can add new columns (events), new rows
(states) and new entries in the content cells (transitions). The language for
de ning tabular editors [
Graphics MPS supports editable graphical notations as shown in Fig. 7. They can be embedded into any other editor. MPS' support for graphical notations is new (available since MPS 3.1, June 2014) and not yet as mature as the rest of MPS, and the API for de ning the editor is not yet as convenient as it should be. The code below shows part of the de nition of the editor for Fig. 7: the contents of a block plus its ports are mapped as the contents of the diagram canvas. diagram { content: this.contents, this.ancestor<Block>.allInPorts().toList, this.ancestor<Block>.allOutPorts().toList palette: custom AccentPaletteActionGroup } Custom Cells MPS supports embedding custom cells. This means that the user can plug in their own subclass of CellProvider and implement speci c layout and paint methods. This way, any notation can be drawn in a low-level way. The cell provider can be parameterized, and ultimately, it can become a new, reusable primitive. Fig. 8 shows an example of a language that reports progress with work packages. It uses three custom cells: horizontal lines (parameterizable with thickness and color), check boxes (that are associated with boolean properties of the underlying language concept) and progress bars (whose percentage and color can be customized, typically by querying other parts of the model). 4
As a language workbench, MPS supports the features known from traditional
IDEs for custom languages. These include code completion, quick xes, syntax
coloring, code folding, goto de nition, nd references and refactorings. In this
section we describe editor features that are speci c to MPS' projectional editor.
Mixed Notations The various notations discussed in the previous section can
all be mixed arbitrarily (with the aforementioned exception of embedding things
into graphical editors). Since all editors use the same projectional architecture
this works seamlessly. In particular, non-textual notations can be used inside
textual notations. Examples include:
{ mathematical symbols embedded in textual programs
{ tables that contain text or math symbols
{ tables embedded in textual programs
{ mathematical symbols embedded in prose
{ lines, progress bar other other shapes embedded arbitrarily
Multiple Editors A single concept can de ne several editors, and a given
program can be edited using any of them. Each of the multiple editors has a tag,
and by setting tags in an editor window (either by the user or programmatically),
the editors corresponding to these tags can be selected. For example, state
machines can be edited in a textual version (roughly similar to Fowler's state
machine DSL [
Partial Syntax Editors can also be partial in the sense that they do not project all contents stored in the AST. Of course the non-projected aspects of the program cannot be edited with this particular editor. But the contents remain stored in the AST (and are cut, copied, pasted or moved) and can be edited later. Using this facility, programs can be edited in ways speci c to the current process step or stakeholder. An example are the requirements traces shown in Fig. 14; programs can be shown with or without them.
Query List An MPS editor normally displays nodes at their phyiscal location. For example, the child condition of the IfStatement shown in Fig. 1 is projected as part of its parent editor. Sometimes, however, it is useful to render nodes in other places. An example is shown in Fig. 9: the grey parts are de ned by the interface realized by the block, but they are still projected for the block itself.
To project nodes in locations where they are not de ned, a querylist editor cell is used (available as part of the mbeddr.platform at http://mbeddr.com). Like other MPS collection cells it projects a list of nodes, but this list is assembled via an arbitrary model query. The result can be projected read-only (as in Fig. 9) or fully editable. The querylist also supports callback functions for adding new nodes (because it is not automtically clear where they would have to be inserted physically) or for deleting existing ones. This way, querylists support views. Tooltips MPS can use the projectional editing facilities in tooltips (available in the mbeddr.platform). To de ne a tooltip, a special cell is inserted into the editor of the cell that should display the tooltip. Since the purpose of a tooltip often is to project information gathered from other parts of the model, tooltip editors often use querylists (Fig. 10).
Conditional Editors Conditional editors essentially support aspect orientation for editor cells. A conditional editor de nes a decoration for existing editors as well as a pointcut that determines to which existing editor cells the decoration is applied. Figures 12 and 13 show examples. Importantly, these conditional editors can be de ned after the fact, and potentially in a di erent language module. This way, arbitrary decorations can be overlaid over exiting syntax. The example in Fig. 12 renders an arrow above all references that have pointer type. Another example could be to change the background color of some nodes based on external data such as pro ling times. By including a tooltip in the de nition of the decoration, users can get more detailed information by hovering over the decorated part of the program. Another use case for conditional editors is the expression debugger shown in Fig. 11.
Annotations Annotations are similar to conditional editors in that they can
render additional syntax around (or next to) existing syntax without the original
syntax de nition being aware of this. However, in contrast to conditional editors,
annotations are additional nodes (i.e., they are additional data in the program)
and not just a property of the projection. The additional nodes are stored as
children of the annotated node. Fig. 14 shows an example in which requirements
traces are added to C code (details are discussed in [
Read-Only Contents Especially in DSLs for non-programmers it is often useful to be able to project rigid, prede ned, non-deletable skeletons of the to-bewritten program in order to guide the user. For example, in Fig. 9, the keywords atomicblock, realizes, contract and ccode, as well as the brackets and lines, are automatically projected as soon as a user instantiates an atomic block. Similarly in Fig. 8, the grey line starting with \last updated" is automatically projected and consists of computed data. In MPS, parts of the syntax of a program can be marked as readonly, meaning that they cannot be deleted or changed. This does not just work for constants (keywords), but for arbitraty content (such as the inherited ports of blocks shown in Fig. 9). 5
In this paper we have discussed the syntactic exibility supported by MPS'
projectional editor. We have described the various supported notational styles
and emphasized that they can be combined exibly. However, it is not enough to
just compose di erent notations { other aspects of languages must be composed
as well. Language composition with MPS is discussed in [
Over the last three years a team at itemis has been developing mbeddr [
Based on this experience we conclude that the notations supported by MPS are reasonably complete relative to the notational styles encountered in practice. Classical textual notations are found in programming languages and DSLs; graphical notations are used by many modeling tools; mathematics are widespread in scienti c or nancial domains; tables are ubiquitous, as the the popularity of Excel demonstrates. And prose (with interspersed program elements) is an important ingredient to almost all these domains (for documentation, requirements or comments).
Acknowledgements Thanks to Bernd Kolb and Niko Stotz for feedback on this paper, and to Niko Stotz for building the margin cell notation.