Defines the kinds of nodes (called Concepts) that may be used in user models. Each node in the program (model) refers to its concept. Concepts specify, which properties, children and references nodes may have. Concepts can extend other Concepts and implement ConceptInterfaces.
- programatic access to the model
- API reference for accessing models
- building AST snippets
- language for pattern matching nodes
Using model & module dependencies from code FAQ
Video - Introduction to JetBrains MPS, part 1: Projects
Video - Introduction to JetBrains MPS, part 2: Structure
Restricts the relationships between nodes as well as the allowed values for properties beyond the rules defined in Structure.
Constraints typicaly define:
- the target scope for references (a collection of allowed nodes a reference can point to)
- situations, in which a node can be a child/parent/ancestor of another node
- allowed values for properties
- property accessor methods (getters and setters)
Video - Introduction to JetBrains MPS, part 3: Constraints
Just like classes in OOP hold methods, Concepts may define methods and static methods that can be invoked on nodes in a polymorphic way. Nodes thus carry behaviour alongside their properties and relationships.
Video - Introduction to JetBrains MPS, part 4: Behavior
Instead of defining a parser that would translate code from an editable form (i.e. text) into the tree-like structure that a computer could manipulate, MPS offers the concept of projectional editor, which let's the user edit the AST directly. The Editor aspect enables language designers to create a UI for editing their concept concepts.
Transformation Menu Language
Context actions tool
Editor language generation API
Video - Introduction to JetBrains MPS, part 5: Editor
The Actions aspect provides means to specify advanced editor behavior, such as copy/paste or node initialization.
Video - Introduction to JetBrains MPS, part 6: Actions (obsolete)
All modern IDEs assist developers with instant code manipulating action available under a handy key-shortcut (Alt + Enter in MPS). Language authors can define such little code transformations for their languages in the Intentions aspect.
Video - Introduction to JetBrains MPS, part 7: Intentions
Models written in one or more languages get ultimately translated into runnable code in some target general-purpose language and platform, such as Java. Along the way models get gradually transformed so that repeatedly concepts get replaced with concepts from a lower level of abstraction until the bottom-line level is reached. The rules for translating concepts and their proper ordering is defined in the Generator aspect.
Building an interpreter cookbook
Video - Introduction to JetBrains MPS, part 8: Generator
During code generation after the Generator has reached the bottom-line AST representation, the TextGen phase kicks in and translates all nodes in the model into their textual representation and saves the resulting textual source files on disk.
Video - Introduction to JetBrains MPS, part 9: TextGen
The ability to understand the flow of values and the flow of control through language constructs helps languages report issues such as unreachable code or potential null-pointer error. Language designer can leverage the Dataflow aspect to define the flow for each concept, which MPS will then use to calculate the dataflow for the whole program.
Video - Introduction to JetBrains MPS, part 10: Dataflow
Language that need to type-check their code need to provide type-system rules. The MPS type-system engine will evaluate the rules on-the-fly, calculate types for nodes and report
errors, wherever the calculated type differs from the expectations.
So called checking rules may additionally be defined to verify non-typesystem assertions about the model.
Video - Physical units extension
Using the typesystem
Debugging the typesystem
Video - Introduction to JetBrains MPS, part 11: Type-system
Modern IDEs allow the developer to seamlessly and flawlessly change the structure of their code through refactoring. MPS allows the language designers to prepare such refactorings and make them part of their languages.
When a new version of a language is released to the public, projects that use the previous version of the language must be migrated so that they use the new language constructs. Migration scripts, prepared by the language authors, will manipulate user code and automatically update it to the most recent version of the language.
Migrations with branching
Various aspects of language definition can be automatically tested. Language authors may create tests that will verify that the editor, actions, type-system, data flow or constraints of their languages behave according to the specifications.
The Accessories Models can be stored at two places - either as an aspect of a language (recommended), or as a regular model under a solution. In both cases, the model needs to be added to the Language Runtime Language Settings so as it could be used. A typical use case would be a default library of Concept instances to be available at any place the language is used.