The MPS 2.0 Future Series: Part 1. The Editor
MPS evolves really quickly. With the 2.0 release getting closer it’s time for us to dip our toes into what’s coming. Today, we’ll discuss the new features targetting the MPS editor.
MPS 2.0 will come with support for tables and diagrams, giving you alternatives to how you write code. Of course, tables and diagrams will be integrated with the existing “textual” notation. For example, tables will be allowed to be embedded in textual code. And the opposite will also be possible – you’ll be able to use textual notations with all the usual editor support inside table cells.
Now, for diagrams the same will be possible, too. For example, in the boxes, or in line labels, textual code will be usable.
How does it sound? Cool, huh? Read on to find out more.
Tables are everywhere
Two flavours of tables will be available: those with a fixed set of colums, as well as tables, in which the columns represent model elements. Since some of you might be lost by now, we’ll illustrate it with an example.
Consider a state machine. A table notation could show the states as rows and the events as columns. Each cell will then contain the transitions that are triggered by an event (column) while the machine is in a given state (row). When you add an additional event, a new column will be added. Selecting a column will result in the selection of the event node.
See a diagram
For diagrams, it is expected that typical box-and-line diagrams will be supported, with boxes and lines representing nodes of your language. A simple auto-layout facility will be included, with an API to integrate other, possibly more advanced layouting engines (such as KIELER or yFiles).
Multiply the editors
Currently a concept in MPS can only have one editor. This works fine for many scenarios, but if you want multiple notations for the same concept, you currently have no other choice than encoding this with a condition in the editor definition. This is neither flexible nor modular.
MPS 2.0 will allow the definition of several editors per concept. Intentions will allow the users to conveniently switch between them. Most likely it will also be possible to define additional editors in sub-languages. For example, you can create a language B that extends a language A, where B redefines the notation for some (or all) of the concepts in A.
The information about how a model is represented (i.e. which notation is used) will be stored in a separate model, outside of the core node structure.
Notice how nicely this plays into diagram notations, which obviously also needs a way to remember the positions and sizes of nodes.
The ability to override/specialize editors will not be limited to complete editor; it will also be possible to override editor components. If the super language provides hooks, sublanguages can “inject” additional editor components into the editors of existing concepts; this way, subconcepts can incrementally adapt editors, as opposed to copy-paste-changing the complete editor of the base concept.
This all is definitely a huge step forward to more modularity of MPS editors.
Default editors
MPS 2.0 will also bring a notion of a default editor for any newly created concept. Due to the “default” nature, it will be more or less tree like. But the important benefit for everyone is that you will be allowed to edit any language immediately after defining its structure. No need to define an editor if you don’t want to. Combine this with the ability to override editors in sublanguages, and you get a convenient way to incrementally provide nicer, more specific notations later.
Conclusion
Well, enough for today. I’ve got a whole bunch of other new features ready for the next part of this series. Till then, please, add your comments below and let us know, what you think.
Develop with pleasure!
-JetBrains MPS Team
Subscribe to MPS Blog updates
