MPS 2020.3 ヘルプ

MPS プロジェクト構造

言語を設計したりコードを書いたりするときには、優れた構造を使用して各部分を移動したり、組み合わせたりすることができます。MPS はこの点で他の IDE と似ています。

プロジェクト

プロジェクトは MPS の主な組織単位です。プロジェクトは 1 つ以上のモジュールで構成されており、それら自体がモデルで構成されています。モデルは生成 / コンパイルの最小単位です。以下でこれらの概念を詳細に説明します。

モデル

Here's a major difference that MPS brings along - programs are not in text form. Ever.
You might be used to the fact that any programming is done in text. You edit text. The text is than parsed by a parser to build an AST. Grammars are typically used to define parsers. AST is then used as the core data structure to work with your program further, either by the compiler to generate runnable code or by an IDE to give you clever code assistance, refactorings and static code analysis.
Now, seeing that AST is such a useful, flexible and powerful data structure, how would it help if we could work with AST from the very beginning, avoiding text, grammar and parsers altogether? Well, this is exactly what MPS does.

To give your code some structure, programs in MPS are organized into models. Think of models as somewhat similar to compilation units in text based languages. To give you an example, BaseLanguage, the bottom-line language in MPS, which builds on Java and extends it in many ways, uses models so that each model represents a Java package. Models typically consist of root nodes, which represent top level declarations, and 非ルートノード . For example, in BaseLanguage classes, interfaces, and enums are root nodes. (You can read more about nodes here ).

モデルはメタ情報を保持する必要があります。

  • 彼らが使用するモデル (インポートモデル)

  • それらが書かれている言語(そして devkits も) (使用言語のセクション)

  • モデルファイルや特別なジェネレーターパラメーターなど、いくつかの追加パラメーター

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.

モジュール

Models themselves are the most fine-grained grouping elements. モジュール organize models into higher level entities. A module typically consists of several models acompanied with meta information describing module's properties and dependencies. MPS distinguishes several types of modules: solutions, languages, devkits, and generators.
We'll now talk about the meta-information structure as well as the individual module types in detail.

モジュールメタ情報

ものをモジュールにまとめるとき、より良い善のためにモジュールを一緒に組み合わせる方法が必要です。モジュール間の関係は、それらが保持するメタ情報を通して記述されます。モジュール間の可能な関係は、いくつかのグループに分類できます。

  • Dependency- if one module depends on another, and so models inside the former can import models from the latter. The reexport property of the dependency relationship indicates whether the dependency is transitive or not. If module A depends on module B with the reexport property set to true, every other module that declares depency on A automatically depends on B as well.

  • Extended language dependency - 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 in the corresponding aspects of language L.

  • 生成ターゲット依存関係 - 2 つの言語(L2 と L1)の間の関係。L2 の生成プログラムが L1 に生成するように指定する必要があるため、L1 の実行時依存関係が必要です。

  • 使用言語 - モジュール A が言語 L を使用している場合、A 内のモデルは言語 L を使用できます。

  • 使用されている devkit - モジュール A が devkit D を使用している場合、A 内のモデルは devkit D を使用できます。

  • ジェネレーター出力パス - ジェネレーターの出力パスは、新しく生成されたすべてのファイルが配置されるフォルダーです。これは MPS があなたのために生成するものを探すことができる場所です。

  • Facets- Facets specify additional technologies or settings that should be available for the module. Facets associated with a module are recorded inside the module descriptor file, which is thus the ultimate source of facet configuration information. All facets, including the テスト and Java ones are completely optional.
    The テスト facet ensures that the generated code will be placed in a directory named test_gen instead of the source_gen location used for ordinary code.
    Beware that unchecking the Java module facet in the Language module properties would exclude the language from the classloading mechanism and thus result in completely different experience.

それでは、MPS にあるさまざまな種類のモジュールについて見ていきます。

ソリューション

解決策は MPS の最も単純な種類のモジュールです。コードを保持し、共通の名前で統一されたモデルのセットです。解決策にはいくつかの種類があります。

  • サンドボックスソリューション - これらのソリューションにはエンドユーザーコードが含まれています。IDE はコードを特別な方法で処理しません。

  • Runtime solutions- these solutions contain code that other modules (Solutions, Languages or Generators) depend on. The code can consist of MPS models as well as of Java classes, sources or jar files. The IDE will reload the classes, whenever they get compiled or changed externally.

  • プラグインソリューション - これらのソリューションは何らかの方法で IDE 機能を拡張します。それらは新しいメニューエントリを提供したり、サイドツールパネルウィンドウを追加したり、プロジェクト設定ダイアログなどからカスタム設定画面を定義したりすることができます。繰り返しますが、MPS はクラスが変更されるたびに再ロードし続けます。さらに、IDE 機能もそれに応じて更新されます。

言語

Language is a module that is more complex than a solution and represents a reusable language. It consists of several models, each defining a certain aspect of the language: structure, editor, actions, typesystem, etc.
Languages can extend other languages. An extending language can then use all concepts from the extended language - derive its own concepts, use 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

  • ランタイムソリューション - これらのモデルはジェネレーター内部のすべてのモデルから見える

言語面

言語の側面は、言語のさまざまな側面を表します。

  • 構造体 - 言語 AST のノードと構造体を記述します。これはあらゆる言語の唯一の必須の側面です。

  • エディター - 言語がエディターでどのように表示され編集されるかを説明します

  • actions - describes the completion menu customizations specific to a language, i.e. what happens when you type Control + Space

  • constraint - AST の制約について説明します。ノードが適用可能な場所、許可されているプロパティおよび参照など。

  • behavior - AST の動作の側面、つまり AST メソッドについて説明します

  • 型システム - 言語で型を計算するための規則について説明します

  • インテンション - インテンションについて説明します (バルブがポップアップしたとき、またはユーザーが Alt+Enter と入力したときに使用できるコンテキスト依存のアクション)

  • プラグイン - 言語を MPS IDE に統合することを可能にします

  • データフロー - コード内の意図されたデータフローを記述します。到達不能なステートメント、初期化されていない読み取りなどを見つけることができます。

このガイドの対応するセクションで各側面についてさらに読むことができます。

ジェネレーター

ジェネレーターは、ある言語から他の言語、通常は別の言語への変換を定義します。ジェネレーターは他のジェネレーターに依存するかもしれません。ジェネレーターにコードを適用する順序は重要であるため、ジェネレーターに順序付け制約を設定できます。対応するセクションで生成についてさらに読むことができます。

DevKits

DevKits have been created to make your life easier. If you have a large group of interconnected languages, you certainly appreciate a way to treat them as a single unit. For example, you may want to import them without listing all of the individual languages. DevKits make this possible. When building a DevKit, you simply list languages to 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.

プロジェクト

これは簡単です。プロジェクトは、グループ化して 1 つのユニットとして操作する必要があるモジュールをラップするだけです。プロジェクトの Propertiesプロジェクトビューパネルのプロジェクトノードの Alt+Enter )を開いて、プロジェクトに含める必要のあるモジュールを追加または削除できます。プロジェクトノードのコンテキストポップアップメニューから新しいモジュールを作成することもできます。

Java コンパイル

MPS は Java から生まれ、Java 環境でよく使われます。MPS モデルは java ファイルに生成されることが多いため、プログラムを実行する前に java をコンパイルする方法が必要です。一般的に 2 つの選択肢があります。

  • MPS でコンパイルする (推奨)

  • IntelliJ IDEA でコンパイルする (IntelliJ IDEA が必要です)

When you compile your classes in MPS, you have to set the module's source path. The source files will be compiled each time the module gets generated, or whenever you invoke compilation manually by the make or rebuild actions.

関連ページ:

基本的な考え方

この章では、基本的な MPS の概念(ノード、概念、および言語)について説明します。これらは、MPS がどのように機能するかを正しく理解するための鍵です。それらはすべて他のものと組み合わせたときにのみ意味をなすため、それらすべてについて一緒に話し合う必要があります。このセクションは、各要素の本質を説明することを目的としています。詳細については、ノード、概念(構造言語)、言語(プロジェクト構造)に関するセクションを確認することを検討してください。抽象構文ツリー (AST):MPS は、テキスト形式...

依存関係を正しくする

目的、便利なキーボードショートカット、ソリューション、ソリューションモデル、プロジェクトへの外部 Java クラスと jar の追加 - ランタイムソリューション、言語、言語モデル / 側面、生成プログラム、目的 :モジュールとモデルは通常、さまざまな型の依存関係のネットワークによって相互接続されて

生成プログラム

MPS ジェネレーターに関する素早い使い方ドキュメントはジェネレータークックブックをチェックしてください。導入:ジェネレーターは、言語の概念の表示的意味論を定義する言語仕様の一部です。MPS はモデル間変換アプローチに従います。MPS ジェネレーターは、入力言語でエンコードされた構文を出力言語でエンコードされた構文に変換することを指定します。モデルからモデルへの変換のプロセスには、多くの中間モデルが含まれる可能性があり、最終的には sn 出力モデルになります。このモデルでは、すべての構造が、セマ...

用語集

MPS 用語集 BaseLanguageJava 6 の投影クローン(Java 7 および 8 のオプションの拡張機能付き)。Java 仕様に準拠し、Java 6. と 1:1 の互換性があります。さらに、MPS は、日付、コレクション、クロージャなど、BaseLanguage に便利な拡張機能をいくつか提供します。コード生成あるモデル(AST)から別のモデルへのコードの変換プロセス。例: 一連のビジネスルールを記述するコードをプレーン Java に変換して、javac でコンパイルし、エンタープライ...