基本的な考え方
この章では、基本的な MPS の概念であるノード、概念、言語について説明します。これらは、MPS の仕組みを正しく理解するための鍵となります。これらはすべて、他の要素と組み合わせることで初めて意味を成すため、すべて一緒に説明する必要があります。このセクションの目的は、各要素の本質を説明することです。詳細については、ノード、概念 (構造言語)、言語 (プロジェクト構造) に関するセクションを確認することを検討してください。
抽象構文木 (AST)
MPS は、テキスト形式を避けることによって他の多くの言語ワークベンチとは一線を画しています。あなたのプログラムは常に AST で表されます。コードを AST として編集し、それをコンパイルした AST として保存し、それを AST としてもコンパイルします。これにより、文法を定義したり、自分の言語用のパーサーを構築したりする必要がなくなります。代わりに、AST ノードのタイプとそれらの相互関係の規則に関して言語を定義します。MPS エディターで作業するほとんどすべてのものが AST ノードで、抽象構文木(AST)に属しています。このドキュメントでは、AST ノードにはより短い名前のノードを使用します。

射影エディター
MPS のエディターは直接 AST を操作します。コードは常にツリー形式で表されるため、解析は不要です。エディターは、言語作成者がデザインした方法で AST をユーザーに提示します。

1 つの言語で複数のプレゼンテーションを利用できます。その場合、ユーザーは任意の時点で適用するコードの視覚化を選択できます。

キーボードでの文字入力を含むすべてのユーザーアクションは、エディターアクションに変換されます。エディターアクションは、AST の対応するノードによって処理されます。
ノード
ノードは木を形成します。各ノードには、親ノード(ルートノードを除く)、子ノード、プロパティ、および他のノードへの参照があります。

AST ノードはモデルに編成されています。ルートノードと呼ばれる、親を持たないノード。これらは言語の最上位の要素です。例: BaseLanguage (MPS の Java に相当)では、ルートノードはクラス、インターフェース、列挙型です。
コンセプト
ノードは互いに大きく異なる場合があります。各ノードは、その宣言、その概念への参照を保存します。コンセプトは、接続されるノードの「タイプ」を設定します。これはノードのクラスを定義し、そのクラス内のノードの構造をコイン化します。これは、ノードのインスタンスが持つことができる子、プロパティ、参照を指定します。概念宣言は継承階層を形成します。ある概念が別の概念を拡張する場合、その概念はすべての子、プロパティ、参照をその親から継承します。
MPS のすべてが AST を中心に展開しているため、概念宣言はそれ自体が AST ノードです。実際、これらは特定の概念、ConceptDeclaration のインスタンスです。

言語
MPS の言語は、いくつかの追加情報を含む一連の概念です。追加情報には、言語に関連するエディター、完了メニュー、インテンション、型システム、データフローなどの詳細が含まれます。この情報は、いくつかの言語の側面を形成します。
明らかに、ある言語は別の言語を拡張することができます。拡張言語は、拡張言語で定義された任意の概念をその子または参照の型として使用でき、その概念は拡張言語の任意の概念から継承できます。ご覧のとおり、MPS の言語は完全に再利用可能なコンポーネントを形成します。
生成プログラム
言語を使用すると、ユーザーはモデルに格納されるコードを作成できますが、ジェネレーターはこれらのソースモデルをターゲットモデルに変換できます。ジェネレーターは、AST モデルで model-to-model 変換を実行します。ターゲットモデルはソースモデルとは異なる言語を使用し、1 つ以上の目的を果たします。
テキストソースファイルに変換してから標準のコンパイラーでコンパイルすることができます (Java、C など)
テキスト文書に変換してそのまま使用することができます (設定、ドキュメント - プロパティファイル、xml、pdf、html、latex)
直接解釈できる
コード解析やサードパーティーのツールによる正式な検証に使用可能 (CBMS、ステートマシンの到達可能性分析など)
実システムのシミュレーションに使用可能
ジェネレーターは通常、ドメインフレームワーク(生成コードが呼び出しまたは継承する一連のライブラリ)に依存しています。フレームワークは目的のソリューションの安定部分をエンコードし、可変部分は実際に生成されたコードに含まれています。

MPS での生成は段階的に行われ、1 つのジェネレーターの出力がパイプライン内の別のジェネレーターの入力になることがあります。オプションの model-to-text 変換フェーズ(TextGen)を続けて、テキスト形式のコードを生成することができます。この段階的なアプローチは、元の問題ドメインと技術的実装ドメイン間の潜在的に大きな意味論のギャップを埋めるのに役立ちます。それはまたジェネレーターの再利用を促進します。
関連ページ:

よくある質問 (FAQ)
ドメイン固有言語、プロジェクショナルエディターおよび MPS:ここでは、MPS に関して最もよくある質問に対する答えを見つけることができます。ドメイン固有言語(DSL)とは何ですか? それらは「実際の」プログラミング言語とどう違うのですか? DSL は、特定の問題領域向けに最適化された言語です。通常、Java、C、Ruby などの汎用言語ほど複雑ではありません。DSL は通常、DSL が設計されているドメインまたはフィールドの専門家と緊密に連携して開発されます。多くの場合、DSL は、DSL が対...

MPS プロジェクト構造
言語を設計したりコードを書いたりするときには、優れた構造を使用して各部分を移動したり、組み合わせたりすることができます。MPS はこの点で他の IDE と似ています。プロジェクト:プロジェクトは MPS の主な組織単位です。プロジェクトは 1 つ以上のモジュールで構成されており、それら自体がモデルで構成されています。モデルは生成 / コンパイルの最小単位です。以下でこれらの概念を詳細に説明します。モデル:MPS がもたらす大きな違いは次のとおりです。プログラムはテキスト形式ではありません。プ...