基本的な考え方

抽象構文木 (AST)

MPS は、テキスト形式を避けることで他の多くの言語ワークベンチと差別化されています。プログラムは常に AST で表現されます。コードの編集も保存もコンパイルもすべて AST で行います。これにより、言語の文法を定義したり、パーサーを構築したりする必要がなくなります。代わりに、AST ノードの型とそれらの相互関係に関するルールに基づいて言語を定義します。MPS エディターで扱うほとんどすべての要素は、抽象構文木 (AST) に属する AST ノードです。このドキュメントでは、AST ノードを「ノード」という短い名前で表します。

射影エディター

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

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

キーボードでの文字入力を含むすべてのユーザー操作は、エディター操作に変換され、その後、AST の対応するノードによって処理されます。

ノード

ノードは木を形成します。各ノードには、親ノード（ルートノードを除く）、子ノード、プロパティ、および他のノードへの参照があります。

AST ノードはモデルに整理されています。親ノードを持たないノードはルートノードと呼ばれます。これらは言語の最上位要素です。例: BaseLanguage （Java の MPS' 対応言語）では、ルートノードはクラス、インターフェース、列挙型です。

コンセプト

ノードは互いに大きく異なる場合があります。各ノードは、その宣言、その概念への参照を保存します。コンセプトは、接続されるノードの「タイプ」を設定します。これはノードのクラスを定義し、そのクラス内のノードの構造をコイン化します。これは、ノードのインスタンスが持つことができる子、プロパティ、参照を指定します。概念宣言は継承階層を形成します。ある概念が別の概念を拡張する場合、その概念はすべての子、プロパティ、参照をその親から継承します。

MPS のすべてが AST を中心に展開しているため、概念宣言はそれ自体が AST ノードです。実際、これらは特定の概念、ConceptDeclaration のインスタンスです。

言語

MPS の言語は、いくつかの追加情報を含む一連の概念です。追加情報には、言語に関連するエディター、完了メニュー、インテンション、型システム、データフローなどの詳細が含まれます。この情報は、いくつかの言語の側面を形成します。

明らかに、ある言語は別の言語を拡張することができます。拡張言語は、拡張言語で定義された任意の概念をその子または参照の型として使用でき、その概念は拡張言語の任意の概念から継承できます。ご覧のとおり、MPS の言語は完全に再利用可能なコンポーネントを形成します。

生成プログラム

言語を使用すると、ユーザーはモデルに格納されるコードを作成できますが、ジェネレーターはこれらのソースモデルをターゲットモデルに変換できます。ジェネレーターは、AST モデルで model-to-model 変換を実行します。ターゲットモデルはソースモデルとは異なる言語を使用し、1 つ以上の目的を果たします。

• テキストソースファイルに変換してから標準のコンパイラーでコンパイルすることができます (Java、C など)

• テキスト文書に変換してそのまま使用することができます (設定、ドキュメント - プロパティファイル、xml、pdf、html、latex)

• 直接解釈できる

• コード解析やサードパーティーのツールによる正式な検証に使用可能 (CBMS、ステートマシンの到達可能性分析など)

• 実システムのシミュレーションに使用可能

ジェネレーターは通常、ドメインフレームワーク（生成コードが呼び出しまたは継承する一連のライブラリ）に依存しています。フレームワークは目的のソリューションの安定部分をエンコードし、可変部分は実際に生成されたコードに含まれています。

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