カスタム言語アスペクトクックブック

カスタムアスペクトの開発サイクル

1. アスペクトを説明する言語を作成します。既存の言語を再利用するか、アスペクトのニーズに固有の言語を作成できます。例: コア MPS アスペクトのそれぞれは、独自の言語セットと、BaseLanguage や smodel などのいくつかの一般的な言語セットを使用します。

2. この言語を (おそらく他の言語を使用して) 他の言語の定義の一部の側面を定義するために使用できることを宣言します。適切な側面記述子を言語で作成する必要があります。

3. 作成した言語でジェネレーターを開発し、アスペクトのランタイムクラスを生成します (必要な場合)。

4. アスペクトのランタイムを使用するアスペクトサブシステムを開発します。

各ステップを詳細に説明します。

サンプルプロジェクトを見回す

CustomAspect サンプルプロジェクトを開くと、6 つのモジュールが表示されます。

ドキュメント言語とそのランタイムソリューションは、他の言語の新しいドキュメントの側面を定義するために使用される重要な構成要素です。アスペクトサブシステムは pluginSolution によって表され、現在フォーカスされているノードの概念に関するドキュメントを表示するアクションを定義します。SampleLanguage ソリューションは、この新しい側面を利用する言語の一例であり、それを使用して独自の概念をドキュメント化します。サンドボックスソリューションは、sampleLanguage の使用箇所を示し、ユーザーがドキュメントアスペクトによって定義されたドキュメントを表示できるようにします。ビルドソリューションは、サンプルプロジェクトを MPS プラグインとしてパッケージ化するビルドスクリプトを定義します。

言語ランタイム

先に進む前に、実行時に言語の側面がどのように機能するのかを考えてみましょう。

• 言語記述子 - MPS の言語ごとに、言語記述子が MPS によって生成されます (クラスは Language.java と呼ばれます)。

• アスペクトインターフェース - 各アスペクトは、ランタイムの API を一連のインターフェースとして定義します。マーカーインターフェース ILanguageAspect を実装する必要があります。

• Language.createAspect() - ここでは言語記述子の createAspect() メソッドに注目してみましょう。アスペクトインターフェースをパラメーターとして指定すると、このメソッドは、この言語のこのアスペクトの具体的な実装を返します (これを AspectDescriptor と呼びます)。

• アスペクト記述子 - AspectDescriptor は、Aspect インターフェースを実装する任意のクラスです。AspectDescriptor には、このアスペクトで記述されるエンティティの getter 以外のコードを含めないことをお勧めします。

これは典型的な言語ランタイムがどのように見えるかです:

createAspect() メソッドは、アスペクトで宣言されたインターフェースの 1 つを期待するパラメーターの型をチェックし、対応する新しくインスタンス化された実装を返します。

これは、アスペクトで定義されたインターフェースがどのように見えるかです（この例はインテンションアスペクトで定義されています）。

カスタムアスペクトの実装

customAspect サンプルプロジェクトを使用してカスタムアスペクトを実装するために必要な手順を詳しく見てみましょう。

1. MPS に特別なモデルをドキュメントアスペクト (つまり、新しいカスタムアスペクト) として扱わせるには、ドキュメント言語でアスペクト宣言を作成する必要があります。これを行うには、言語でプラグインアスペクトを作成し、jetbrains.mps.lang.aspect 言語をインポートします。

   

2. 言語のプラグインモデルにアスペクト宣言を作成し、そのフィールドに入力します。これは MPS にこの言語が他の言語のための新しいカスタムアスペクトを実装するために使われることができることを伝えます。

   

3. ドキュメント言語を作成 / 再構築した後、サンプル言語でドキュメントアスペクトを作成し、その中にドキュメントコンセプトを作成することはすでに可能です。

   

4. ConceptDocumentation コンセプトのインスタンスは、ドキュメントの側面で作成できます。

   

5. ここで、MPS 内で動作する新しいアスペクトの機能を指定するために、言語ランタイムに移動する必要があります。この例では、選択した概念のドキュメントを取得して返すことができるインターフェースを作成しましょう。これを行うには、ランタイムソリューションを作成し、それをドキュメント言語のランタイムモジュールとして追加し、その中にインターフェースを作成します。インターフェースは ILanguageAspect インターフェースを拡張する必要があることに注意してください。ここでのインターフェースに必要なのは、概念をパラメーターとして受け取り、対応するドキュメントテキストを含む文字列を返すメソッド 1 つだけです。

   

6. 次に、ドキュメント言語のジェネレーターで、インターフェースの実装を提供する必要があります。条件付きルートルールと次のテンプレートがうまく機能し、ドキュメント記述子クラスを生成します。

   

   この条件により、カスタムアスペクトのモデル、つまり、この例ではドキュメント定義 (jetbrains.mps.samples.customAspect.sampleLanguage.documentation) を保持するモデルに対してのみルールがトリガーされることが保証されます。ここでの便利な機能は、コンセプトスイッチの構造です。これにより、概念実装の詳細を無視できます。これは、ドキュメント化されたすべての概念 (LOOP マクロ) を単純にループし、そのような概念ごとに、関連する ConceptDocumentation から取得した文字列値を返す一致するケース (正確には ->$[ConceptDocumentation]) を作成します。

7. インターフェースと実装クラスがあります。ここで、結び付ける必要があります。言語ランタイムクラスの createAspect メソッドの一部を生成する必要があります。これにより、コンセプトがインスタンス化されます。つまり、ドキュメントアスペクトが必要なときは常に (DocumentationAspectDescriptor インターフェースを渡すことによって)、生成された DocumentationDescriptor クラス。

   
   

   以下の動作を理解するには、Language.java クラスがどのように生成されるかを見てください (モデル jmlang.descriptor.generator.template.main の Language クラスを参照)。記述子のインスタンス化は、jetbrains.mps.lang.descriptor クラスの AspectDescriptor_Instantiate というテンプレートスイッチによって行われます。これは、もう 1 つのアスペクトモデルで動作するように、新しいアスペクト言語で拡張する必要があります。

   

   基本的に、生成された言語 クラスに DocumentationAspectDescriptor インターフェースのチェックを追加し、要求された aspectClass がカスタムアスペクトインターフェースである場合は、DocumentationDescriptor の新しいインスタンスを返します。

8. 残っているのは私たちの新しい側面を使うことだけです。そのためには、カーソルがオンデマンドでオンになっているノードの概念に関するドキュメントを表示するアクションを作成する必要があります。

   

   NS コンテキストパラメーターを指定できるようにするには、モデルをインポートする必要があります。アクションは、StandalonePluginDescriptor を使用して（新しく作成された）プラグインソリューション（プラグインのプラグインソリューションの詳細）の一部として作成し、ActionGroupDeclaration を介してメニューにフックする必要があります。

   

9. 

   このようにして、IDE コードメニューが強化されます。

10. 試してみましょう ! プロジェクトを再構築し、サンドボックス ソリューションで DocumentedConcept コンセプトのノードを作成または開き、コードメニューからドキュメントの表示アクションを呼び出します。