This meta information can be altered in Model Properties of the model's pop-up menu or using Alt + Enter when positioned on the model.
Module meta information
To describe relations between Now when we have stuff organized into modules, we store meta information inside them. Here are the kinds of relations in which modules can participateneed a way to combine the modules together for better good. Relationships between modules are described through meta information they hold. The possible relationships among modules can be categorized into several groups:
- Dependency - if one module depends on another, and so models inside the former can import models from the latter. This relation is parameterized by The reexport property of the dependency relationship indicates whenther the dependency is transitive or not. If module A depends on module B with the reexport property set to true, every other module that depends declares depency on A automatically has B in its dependencies listdepends on B as well.
- Used language - if module A uses language L, then models inside A can use language L.
- Used devkit - if module A uses devkit D, then models inside A can use devkit D.
- Extended language - if language L extends language M, then every concept from M can be used inside L as a target of a role or an extended concept. Also, all the aspects from language M are available for use and extension from in the corresponding aspects in of language L.
- Generator output path - generator output path is a folder where all newly generated files will be put.placed. This is the place you can look for the stuff MPS generates for you.
Now we'll look at the different types of modules you can find in MPS.
Solution is the simplest possible kind of module in MPS. It is just a set of models with unified under a common name.
Language is a module that is more complex than a solution and represents a reusable language. It consists of aspect modelsseveral models, each defining a certain aspect of the language: structure, editor, actions, typesystem, etc.
Languages can extend other languages, which means they can use . An extending language can then use all concepts from an the extended language . They can - derive its own concepts from an extended language, use them as a target of a reference, and store them as children.Since usually we generate language in some code and this code requires some support classes, languages can have runtime classpath and runtime solutions. Runtime classpath just makes available classes from it as java_stub to language's generators. Runtime solutions' models are visible to models inside the generator. Using runtime classpath is recommended when your runtime is written in java and is quite simple. In more complex situations, it is recommended to create a runtime solution.inherited concepts as targets for references and also place inherited concepts directly as children inside its own concepts.
Languages frequently have runtime dependencies on third-party libraries or solutions. You may, for example, create a language wrapping any Java library, such as Hibernate or Swt. Your language will then give the users a better and smoother alternative to the standard Java API that these libraries come with.
Now, for your language to work, you need to include the wrapped library with your language. You do it either through a runtime classpath or through a runtime solution. Runtime classpath is suitable for typical scenarios, such as Java-written libraries, while runtime solutions should be prefered for more complex scenarios.
- Runtime classpath - makes library classes available as stubs language generators
- Runtime solutions - these models are visible to all models inside the generator
Language aspects describe different facets of a language. The only mandatory aspect is structure. Without it language is meaningless. Here are the available aspects:
- structure - describes the nodes and structure of the language AST. This is the only mandatory aspect of any language.
- editor - describes how a language will be presented and edited in the editor
- actions - describes the completion menu customizations specific to a language, i.e. what happens when you type Control + Space
- constraints - describes the constraints on AST: where a node is applicable, which property and reference are allowed to it , etc.
- behavior - describes the behavioral aspect of AST, i.e. AST methods
- typesystem - describes the rules for calculating types in a language
- intentions - describes intentions (context dependent actions available when light bulb pops up or when the user types Alt + Enter)
- plugin - allows a language to integrate into MPS IDE
- data flow - describes data the intented flow aspect of a languagedata in code. It allows you to find unreachable statements, uninitialized reads etc.
- scripts - ???
You can read more about each aspect in the corresponding section of this guide.
Generators describe define possible transformations of a language . They can into something else, typically into another languages. Generators may depend on other generators and have generator constraints which describe in which order transformations should be applied. Since the order in which generators are applied to code is important, ordering constraints can be set on generators. You can read more about generation in the corresponding section.
When DevKits have been created to make your life easier. If you have a large set group of interconnected languages, you want certainly appreciate a way to treat them as a single unit. For example, you may want to import them without listing all of these languages in the used individual languages section of a model. Devkits DevKits make this possible. In devkitWhen building a DevKit, you simply list languages which will be automatically imported on devkit addition. Devkits can extend other devkits, in which case all languages from these devkits will be available in models used by extended devkitto include.
As expected, DevKits can extend other DevKits. The extending DevKit will then carry along all the inherited languages as if they were its own ones.
Project is just a set of modules with which you workThis one is easy. A project simply wraps modules that you need to group together and work with them as a unit.
Since we often generate MPS models to MPS was born from Java and is frequently used in Java environment. Since MPS models are often generated into java files, we have a way to compile themjava is needed before we can run our programs. There are generally two options for this task: compiling classes :
- Compiling in MPS (recommended)
- Compiling in IntelliJ IDEA (requires IntelliJ IDEA)
When you compile your classes in MPS, you have to set the module's source path. These The source files will be compiled on module generationeach time the module gets generated, or when whenever you invoke compilation manually with by the make or rebuild actionactions.