Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Defining A Typesystem For Your Language

Anchor
what_is
what_is

This page describes the MPS type-system to a great detail. If you would prefer a more lightweight introduction into defining your first type-system rules, consider checking out the Type-system cookbook.

...

Literals or expressions usually have associated type inference rules that get triggered when the typechecker requires type of the node in question. The rules have a mechanism allowing subconcepts to extend or override the predefined rule. 

rule typeof_IntLiteral {   applicable for concept = IntLiteral as nodeToCheck
applicable always
overrides false
overrides true
do {
typeof(nodeToCheck) :==: <integer>;
}
}

Inference rules for node attributes

...

lookup-inference-rules(node) :
  let skipAttributed = false
  foreach a in attributesOf(node) do
    if hasInferenceRuleFor(a) then
      let rule = getInferenceRuleFor(a)
      yield rule
if isSuperceding(rule) then
        let skipAttributed = true
end if
      if isOverriding(rule) then
        returnbreak foreach loop
      end if
     end if
  end do

  if skipAttributed then
    return
  end if

  /* proceed as usual */
end

An example of using an inference rule applicable to a node attribute shows how the presence condition can alter the type of a literal. Note that in this example the type of the annotated literal is affected by by both this inference rule and any other inference rule applicable to the node.

rule typeof_Literal {   applicable for concept = PresenceConditionAnnotation as pca
applicable always
overrides truefalse 
supercedes attributed false
 do {
typeof(pca.parent) :<==: pca.alternativeNode
}
}
 

Conditionally overriding type inference

...

rule typeof_Literal {
  applicable for concept = PresenceConditionAnnotation as pea
applicable always
overridessupercedes attributed { 
    isConditionSatisfied(pca);
}
do {
typeof(attributedNode) :==: pca.replacementType
}
}

Checking rules

Checking, (or Non-typesystem) rules can inspect the model searching for known error patterns in code and report them to the user. This kind of pre-compilation code inspection is generally known as static code analysis. Error patterns in typical tools for static code analysis can fall into several categories, such as correctness problems, multi-threaded correctness, I18N problems, vulnerability-increasing errors, styling issues, performance problems, etc. The found issues are reported to the user either on-demand through an interactive report:

Image Added

or in a on-the-fly mode directly in the editor by colorful symbols and code underlines:

Image Added

Severity

MPS distinguishes problems by severity:

  • errors - displayed in red
  • warnings - displayed in yellow
  • infos - displayed in grayish

The jetbrains.mps.lang.typesystem language offers corresponding statements that emit these problem categories together with their description and the node to highlight. The additional ensure statement gives the user a more succinct syntax to report an error in case a condition is not met:

Image Added

Checking rules typically check for one or a few related issues in a given node or a small part of the model and report to the user, if a problem is discovered:

Image Added

Quick-fixes

quick-fix provides a single model-transforming function, which will automatically eliminate the reported problem:

Image Added

quick-fix must provide a description to represent it in the Intentions context menu, unless it is only ever referred to from callers with apply immediately set to true. A quick-fix may also declare fields, to hold reused values, and it can accept arguments from the caller.

Invoking quick-fixes

A quick-fix may be associated with each reported problem through the Inspector tool window using the intention to fix:

Image Added

Normally the user invokes the quick-fix through the Intentions context menu, which is displayed after pressing the Alt + Enter key shortcut. If the apply immediately flag is set, however, MPS will run the associated quick-fix as soon as the problem is discovered during on-the-fly analysis without waiting for the user trigger.

Image Added

The two other optional properties configured through the Inspector are needed less frequently:

  • node feature to highlight - specifies a node's property, child of reference to highlight as the source of the problem, instead of highlighting the whole node
  • foreign message source - when a user clicks (Control/Cmd + Alt + click) on the reported error in the editor, she is taken to the Checking rule's error/warning/info/ensure command that raised that error. With the foreign message source property you can override this behavior and provide your own node that the user will be taken to upon clicking on the error.

 

Previous Next