JetBrains MPS Blog

In this last part of our MPS future series, we’ll have a brief look at the project itself and discuss its properties with respect to the community around it.

Grabbing MPS

As most of you probably know, the MPS source code is already available (see a blog post mentioning the details). Shared source code, however, is not the only useful attribute of a good open source project. We plan to publicly share MPS daily and milestone builds for anyone to download.
The MPS website itself will soon be enhanced, too. It needs to include a lot more community-oriented features in addition to the already-existing bugtracker - it will host a wiki for community-built documentation, various code examples as well as on-line help.
We believe all these changes will result in enhanced communication and cooperation between all the people interested in the future of Domain Specific Languages.

Conclusion

In this three-part series we’ve looked under the hood of MPS 2.0. You see there’s a lot to look forward to. Although the plans may still change and features get re-prioritized, you could now have a sound idea of where the project is heading.

This document only highlighted the most important features. If you want to see details, and also track the progress, you should take a look at the MPS issue tracker.
Specifically, this search will give you the issues related to MPS 2.0. All these requests are only “plan items” for 2.0. We will probably fix a huge number of “normal bugs” along the way as well

The latest milestone builds are available for download from the MPS 2.0 EAP download page and you can follow development also through the MPS blog.

Develop with pleasure!
-JetBrains MPS Team

We’ve talked a lot about the editor enhancements making in into MPS 2.0. Now let’s move on from the editor to other topics.

No comment, or yes?

An important improvement for everyone to benefit will be the addition of a base language for documentation and comments. By embeding this language in any of your own languages, you will be allowed to use rich text documentation inlined in your language’s program code.
One feature in particular is very interesting: you will be able to insert other nodes in the free-flowing documentation text. These could, among other things, reference yet other language nodes. So, for example, if you work with a language for expressing insurance contract rules, you can embed variable declarations and/or references to calculation rules into the flowing text, resulting in a nice integrated approach to mixing formal models and free flowing text.

A somewhat related functionality is comment-out, working for any language. As expected, commented out code will not be seen by other (referencing) nodes or by generators.

What’s your version number?

Let’s now turn to the version control integration. A couple of enhancements are planned here as well.

• VCS annotations will be supported directly from the editor
• The project and model properties will be diff-able. This is very useful, since these property files can themselves be non-trivial, and better VCS support here is very much appreciated.
• Diffs will be possible on per root node, and not just per model.
• Histories for roots will be supported.

Modules

Another major area for enhancements is the modularization of MPS itself. Now, this is very important, since it will, among other benefits, make MPS DSLs accessible to non-programmers.
The goal here is to be able to

• Easily create standalone applications that only contain one or more MPS languages, getting rid of the “language development UI/features” UI complexity.
• Deploy an MPS language as a plugin into IDEA

To demonstrate this, several such standalone “MPS applications” are currently under development.

Generator

As most of the other parts of MPS, the generator will also be enhanced. One important improvement is to allow parametrization of generators.
When a generator is invoked, values for the parameters can be set, for example through a facet. These values are then used in mapping configurations and in templates to determine exactly how the code generation should proceed.

Facets

MPS will also inherit IDEA’s concept of facets (a similar concept is available in Eclipse as Natures). A facet is a way to define certain characteristics of a project. Specifically, they can configure generators, through the parameters mentioned in the previous paragraph. Facets can also contribute additional UI elements to MPS itself. You’ll be able to define facets as a language aspect.

Other

There will be a large set of smaller improvements, including:

• Improvements to the collection and closure languages
• Pasting in from normal (i.e. ASCII-textual) Java code.
• Enhancements to the debugger, which have already been included into the first two Milestone Builds

Conclusion

Wow, that was quite a ride, wasn’t it. Now it is your turn to give us your feedback while the info is still hot in your head. Please use the comment section below and let us adopt MPS to your needs.

Develop with pleasure!
-JetBrains MPS Team

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

Language of mathematics contains a lot of domain specific constructs. Almost every part of mathematics has its own domain specific “extensions”. So it’s a good idea to borrow from there. In MPS we have a special base language extension that contains some mathematical notation. In this post we will consider one of such notations that we borrowed from mathematics.

We quite often write code that checks whether a value lies in a specific range. This is especially widespread in a code working with graphics. We might write something like this:

This piece of code checks whether a point lies inside a rectangle. Quite boring, isn’t it? In our jetbrains.mps.baseLanguage.math language we have support for intervals. Instead of the code above, you can write this:

As you can see it is shorter and much easier to read. Intervals, in the language can be open or closed. For example you can write this:

They can even contain infinities:

This language feature will be available in MPS 1.0. In addition to the intervals MPS will provide other mathematical notations, for example sums. We will write about them in one of the following posts.

Posted by Konstantin Solomatov, Lead MPS developer

Many functional and dynamic languages have “tuples” in their syntax. Tuple is a sequence of a fixed length. For example, pair, triple and quadruple are tuples. They are very useful when you have algorithms operating on entities which have two, three or more parts and you don’t want to create devoted classes for them, or if you want to return multiple instances from a method.

Let’s take a closer look at how tuples are implemented in MPS.

We have a tuple type. Here is a pair of String and int:

We have a special syntax for tuple construction: we added a new type of literal to the base language:

Each element of a tuple has a name by which it can be accessed:

Tuples are immutable, so you can only create new tuples but can’t change the existing ones. If two tuples contain same element types but different names they are compatible. I.e. you can write:

It took us only about half a day to implement such a cool features in MPS, so it isn’t really hard to do. This feature is going to be available in MPS Beta 2.

MPS Beta 2 should be available next week. Check back at MPS web site or at this blog for the announcement.

Posted by Konstantin Solomatov, Lead MPS developer