Child pages
  • What's new in MPS 3.3 EAP2
Skip to end of metadata
Go to start of metadata


Attribute support in TextGen and Generator

A prototype of the feature comes as part of EAP2. It can be considered to be in a 'Proof of concept+' state. Node Attributes are handled both in TextGen and Generator. In TextGen, an attribute on a node changes the control flow, and a TextGen component of an attribute takes precedence over that of the attributed node, pretty much like it's done in the editor aspect. There's a new 'attributed node' append part, available in the textgen components of NodeAttribute, to delegate to the component of the attributed node. Unlike TextGen, Generator merely preserves particular node attributes during the transformation process - attributes do not affect the control flow of the process.

For migration purposes, attribute processing could be switched off in the Generator settings (the TextGen section, 'Enable node attributes') in case there's code that processes node attributes (particularly in TextGen) manually. Note, however, that MPS itself now depends on attributes, as the JavaDoc tags are implemented as NoteAttributes and thus the generation of Java code relies on these attributes to get comments generated (you might face missing javadoc attributes if you turn this option off). Attribute processing in TextGen is deemed complete.

For node attributes to survive the generation process, it's vital for them to implement a marker interface PersistGeneration. We aim to lift the restriction later, when 'Phase 2' comes to life, with sophisticated handling of attribute meta-information. Processing of node attributes during generation is guarded by aforementioned setting as well. The present state seems sufficient to give the feature a try and to confirm that the desires behind the feature and its implementation are on the same page.

There's sample project you might find handy, 'jetbrains.mps.samples.attribute', to show few simple scenarios.

TextGen changes

In addition to node attribute handling, TextGen component has been refactored significantly. It's now part of the general language aspect loading mechanism (reflective access is supported for compatibility with TextGen aspects generated in MPS 3.2, it's highly recommended to re-build your textgen aspect model, nevertheless). Besides changes in node attribute handling (see above for details, and also, there's a change in the convention how files emerge from a model. Unless your language extends concepts of another language, and relies on the TextGen of the extended language, there's nothing to worry about. MPS used to create a file for each root concept, including sub-concepts, of a language. Now, only exact concept matches are considered, and if an extending concept desires to re-use textgen component of an ancestor, it shall declare its own, empty TextGen component, stating essentials as the file name, encoding and extension, and leaving the body of the component empty. For details, see It is a part of an ongoing process to separate the text generation control from the file management.


If your TextGen relies on inheriting the TextGen definition from super-concepts, this change is likely to break your models. Please create empty TextGen definitions for your sub-concepts to resolve the issue.


Generic support for commenting out nodes

MPS now provides a universal way to comment out nodes in models. In previous versions this functionality had to be implemented in all languages separately, either through node attributes or dedicated "comment" nodes. In 3.3 the information about a node being commented out is stored in the model in a generic way. The smodel language ignores commented out nodes by default so that your queries do not have to filter out commented out nodes explicitly. Additionally, actions have been created to comment/uncomment out a node.


If you implemented a custom way of commenting out nodes for your languages in previous versions of MPS, this custom functionality of yours may appear to be broken, or at least obsolete, under MPS 3.3. The Control/Cmd + / key shortcut is now taken by the generic comment-out action and will not work for custom implementations. With little customization work the generic functionality could be adopted to work smoothly for your languages and so you could migrate away from the custom implementation. A semi-automated process for migrating the comments is available. See the documentation on generic commenting out for full description of the feature.


Using annotations to override inference rules for expressions/literals

Type Substitution Annotations have been introduced in order to reduce the boilerplate required in order to implement type substitutions. Types are represented in code as nodes, now with optional substitute annotations. The annotations are implemented as node attributes. The annotations help transform the type when introduced to the type-checking engine at runtime, much like the editor uses attributes to provide alternative cell editors. There is now also support for overriding the type inference rules for literals or expressions that have specific annotations. The inference rule activated by an annotation has greater priority than the default one defined for the node itself.

Intention and script aspects plug in as generated language aspects now

This is a change that you are unlikely to notice, still it is worth a good mention. These aspects used to have been pulled in into MPS through java reflection, while now they are registered into the runtime with the same general mechanism that most of the other language aspects use, i.e. part of a generated language runtime class. Though we keep backward compatibility with code generated in MPS 3.2, it's recommended to rebuild intention and script aspects of your languages before attempting to use the functionality they provide.

  • No labels