MPS 2023.3 ヘルプ

基本的な考え方

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

抽象構文木 (AST)

MPS は、テキスト形式を避けることによって他の多くの言語ワークベンチとは一線を画しています。あなたのプログラムは常に AST で表されます。コードを AST として編集し、それをコンパイルした AST として保存し、それを AST としてもコンパイルします。これにより、文法を定義したり、自分の言語用のパーサーを構築したりする必要がなくなります。代わりに、AST ノードのタイプとそれらの相互関係の規則に関して言語を定義します。MPS エディターで作業するほとんどすべてのものが AST ノードで、抽象構文木(AST)に属しています。このドキュメントでは、AST ノードにはより短い名前のノードを使用します。

AST.png

プロジェクションエディター

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

DSGN-5911-sliders-MPS-b-04.png

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

DSGN-5911-sliders-MPS-b-06.png

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

ノード

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

basicNotions.png

AST ノードはモデルに編成されています。ルートノードと呼ばれる、親を持たないノード。これらは言語の最上位の要素です。例: BaseLanguage (MPS の Java に相当)では、ルートノードはクラス、インターフェース、列挙型です。

コンセプト

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

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

concepts.png

言語

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

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

生成プログラム

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

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

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

  • 直接解釈できる

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

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

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

Domain-framework.png

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