« May 2006 | Main | July 2006 »
June 22, 2006
New build #292 is out
The new MPS build #292 is out.
I would like to mention one small improvement in this build, which makes the default behavior of the MPS's editor more intelligent.
The default behavior is the set of editing actions that are available just after cells layout for a language concept is defined.
In particular, there is a code-completion action (ctrl-space) which often results in showing of the code-completion menu.
Let's take a look at a local variable declaration (baseLanguage) and code-completion menu for the type of the variable:
From the baseLanguage's structure we know that the variable type should be instance of the Type concept.
View image
Thus, the editor proposes to instantiate the BooleanType (which is successor of the abstract Type concept), IntegerType and other primitives.
But the baseLanguage also defines the ClassifierType which is, in essence, a reference to a Classifier. And what we need is not to merely instantiate ClassifierType but also create a reference to an existing Classifier.
In other words we don't need the ClassifierType in the code-completion menu but names of the classes to choose from.
In the past, such behavior required substantial amount of the customization code to be written. But not any more.
Now the editor is able to automatically detect concepts that are, in fact, merely references, find suitable referent nodes and build auto-completion menu accordingly. Big relief.
Simplistically, the "merely reference" is a concept which declares one reference with multiplicity 1, not abstract and not marked as "doNotSubstituteByDefault".
In addition, this concept shouldn't provide custom matching text to the auto-completion menu.
In our example, the ClassifierType satisfies these conditions.
Let's take another example - the NewExpression concept.
Judging from its structure the NewExpression concept is "merely reference" - it declares one reference with multiplicity 1, not abstract and not marked as "doNotSubstituteByDefault".
But it provides custom matching text (it has alias="new").
View image
So editor doesn't consider it to be "merely reference".
Indeed, an instance of the NewExpression is rendered as new Classname(...).
Thus, the desired sequence of actions is to first choose the "new" from the auto-completion and then choose a constructor.
Returning to the example with the ClassifierType, I've simplified the situation a bit.
Strictly speaking, the concept's structure alone is not enough.
The problem is that in our auto-completion menu we don't want to see *all* classes available in the project.
We are only interested in classes located in the current model and in its imported models.
Such a scope narrowing can be done using model constraints.
I've already blogged about the new constraints language.
Here is how such constraint looks like. It defines search scope for targets of the "classifier" link in the ClassifierType concept.
The "create" function returns an object of type ISearchScope (interface declared in package jetbrains.mps.smodel.search).
Typically, the implementation of ISearchScope is straightforward. It wraps some arbitrary data and implements method
List<SNode> getNodes(Condition<SNode> condition);
which returns a list of nodes satisfying a certain condition.
Posted by Igor Alshannikov at 08:21 PM | Comments (0)
June 05, 2006
MPS Constraints Language
Recently the new language has enriched the family of the MPS bootstrap languages - the Constraints Language.
A language definition now may include a constraints model which allows to attach additional logic to the features defined in the structure model of the language.
The language constraints model would enforce model integrity and allow to build more intelligent default behavior of the MPS editor.
There were different kinds of constrains before, of course. First are very simple, wired into the Structure Language (like link multiplicity 0..1, 0..n etc.) constraints, and others are extremely flexible but considerably more complex rules, enabling type checking and type inference.
The Constraints Language lies somewhere between these two extremes, combining both simplicity and flexibility.
Currently, the Constraints language is very small and not complete, it only includes facilities that needed immediately. Namely, there are only two kinds of constraints: one is for a property declaration and the second is for a reference link declaration.
For a property declaration a user can define a value-computation function, and
for a reference link declaration the user can define a function that will compute so-called 'referent search scope'.
Here is an example of the property constraint applicable to the name of a class constructor:
Posted by Igor Alshannikov at 09:26 PM | Comments (0)