A common useful case for ‘can be parent’ constraints in MPS

Imagine you have a (very contrived) language as shown below (i.e. some root that contains children of an abstract concept named A and Bs and Cs extend A):

mps-metamodel

By default, all As and Bs can be substituted (Ctrl/Cmd+Space) in the nlist of MyRoot:

mps-constraints-editor-before

Now, if we want to restrict this, to, let’s say, only Bs, then we can use a ‘can be parent’ constraint on MyRoot that looks like this:

mps-constraints-editor-after

Note that you can’t use childNode.isInstanceOf(B), since this would only work when the childNode is already instantiated (so it would give you an empty completion menu as an uninstantiated child node is not and will never be an instance of B.

The resulting completion in the editor looks like this:

mps-constraints-editor-onlyb

This type of construction is especially useful if you make a language which extends another language that you don’t want to change, but of which you want to restrict certain concepts in your extension.

An example of this (currently for MPS2018.1.5) can be found here: https://github.com/DSLFoundry/mps-examples/tree/master/ChildConstraints

Leave a Comment