メタプログラミング：それが何であり、どうあるべきか

メタプログラミングは、作業の結果として他のプログラムを生成するプログラムの作成に関連する一種のプログラミングです（ wiki ）。 これはかなり一般的な用語であり、同じウィキペディアによれば、外部ツール、さまざまなプリプロセッサー、および「コンパイラーへのプラグイン」によるソースコードの生成を指します。自己修正コードとして-実行時のプログラム自体によるプログラムの修正。



もちろん、自己修正コードはむしろ別の大きなトピックであり、別の研究に値します。 ここで、メタプログラミングとは、プログラムのコンパイル中に発生するプロセスを意味します。



メタプログラミングは、まったく異なる言語である程度実装されています。 エキゾチックで類似した言語を考慮しない場合、メタプログラミングの最も有名な例は、テンプレートシステムを備えたC ++です。 「新しい」言語のうち、DとNimを検討できます。 メタプログラミングの実装で最も成功した試みの1つは、Nemerle言語です。 実際、この4つの例では、主題を検討します。



メタプログラミングは興味深いトピックです。 この記事では、それが何であり、理想的な場合にどうあるべきかを理解しようとします。

コンパイル手順

トピックの説明を始める前に、コンパイラの動作を確認する必要があります。

そのため、コンパイラの入力には、プログラムテキスト形式のソースコードがあります。



コンパイルの最初の段階は、 字句解析です。 この段階で、プログラムはソリッドテキストからトークン（トークン）に分割されます。各変数、リテラル、演算子、キーワード、コメントは個別のオブジェクトになります。 もちろん、このようなオブジェクトを使用する方が、ソース行を直接使用するよりもはるかに便利です。



次のステップは構文解析で、構文ツリーを構築します。 この段階で、線形構造は階層的になります。 プログラムを書くときに私たちが実際に表現するものに。 クラス、関数、コードブロック、操作は、抽象構文ツリー（AST）のノードになります。 解析自体は多くのステップで構成されています。 これには、型の操作（型推論を含む）、およびさまざまな最適化が含まれます。



最終段階はコード生成です。 構文ツリーに基づいて、仮想および/またはマシンコードが生成されます。 それはすべてターゲットアーキテクチャに依存します。レジスタとメモリが割り当てられ、ツリーノードが一連のコマンドに変わり、追​​加の最適化が実行されます。



主に字句解析と構文解析に関心があります（ただし、コード生成の段階でメタプログラミングも可能ですが、これは別の大きな完全に未探索のトピックです）。

字句マクロ

今日まで残っている最も古いメタプログラミングツールの1つは、システムプリプロセッサです。 おそらく、最初のプリプロセッサは実際には別個のプログラムであり、前処理の後、作業の結果をソーステキスト形式に戻しました。 プリプロセッサはトークンレベルで動作するため、つまりトークンのシーケンスを受信した後（実際には、プリプロセッサはその目的のために、たとえば引数を持つ独自のマクロに対して、最も単純な解析を実行しますが）、レキシカルです。 プリプロセッサは、トークンの1つのシーケンスを他のものに置き換えることができます。 彼はプログラムの構文構造について何も知らない-だから有名にするのはとても簡単だ

#define true false
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「システム全体の」プリプロセッサの問題は、一方では、プログラムがプレーンテキストとあまり変わらないときの字句解析の後、早すぎることです。 一方、それは本格的なプログラミング言語ではなく、条件付きコンパイルとトークンのシーケンスを他のものに置き換えるだけのシステムです。 もちろん、これで多くのことを行うことができます（ boost.preprocessorを参照）が、それでも本格的な（そして最も重要なのは理解可能で便利な）メタプログラミングには達しません。

C ++テンプレート

次によく知られているメタプログラミングツールはC ++テンプレートです。これは、パラメーター化されたクラスと関数を作成できる構造です。 テンプレートは、大きなマクロとは異なり、すでに構文ツリーで機能します。 C ++で最も一般的なテンプレートを検討してください

 template<class T, int N> struct Array { T data[N]; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

およびそのアプリケーション（インスタンス化）：

 Array<int,100> arr;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイラの観点から何が起こっていますか？ テンプレート構造は、別個の特別なASTアセンブリです。 テンプレートには、タイプと整数定数の2つのパラメーターがあります。 テンプレートのインスタンス化の時点で、正式なパラメーター名ではなく、テンプレートパラメーター（実際にはASTノードでもある）がテンプレート本体に置き換えられます。 その結果、メイン構文ツリーで使用されるノードが作成されます（または以前に作成されたものを検索します）。 ここで重要なのは、テンプレート自体とインスタンス化ポイントのテンプレートパラメータの両方が単なるタイプと番号ではなく、構文ツリーのノードであるということです 。 つまり、int型と数値100を渡すことにより、実際には2つの小さな構文ツリー（この場合は1つのノード）を構築して、より大きな構文ツリー（テンプレート本体）に転送し、その結果、メインに挿入される新しいツリーを取得します構文ツリー。 これは、sichenマクロを置き換えるメカニズムのように見えますが、すでに構文ツリーのレベルにあります。



もちろん、テンプレートパラメータは、より複雑な構造にすることもできます（たとえば、std :: vector <std :: set <int >>を型として渡すことができます）。 しかし、C ++テンプレートの機能の根本的な不完全さに注意を払うべき時が来ました。 標準の14.1節によれば、テンプレートパラメーターは型と一部の非型（整数、列挙要素、クラスメンバーへのポインター、グローバルオブジェクトへのポインター、関数へのポインター）のみです。 一般に、ロジックは明確です-リストにはコンパイル段階で決定できるものがあります。 しかし、たとえば、不明な理由により、文字列や浮動小数点数は含まれていません。 また、パラメーターがASTノードであることを覚えていれば、他に多くの有用なものがないことが明らかになります。 それでは、たとえば変数の名前やコードのブロックなど、任意のASTノードをパラメーターとして渡すことを妨げるものは何ですか？ 同様に、パターン自体はクラス（構造）または関数のみです。 そして、コードの任意のブロックがテンプレートを作成するのを妨げるものは何ですか-命令型（制御演算子、式）と宣言型（たとえば、構造体または列挙の断片）の両方ですか？ C ++自体にはこのような機能がないことに他なりません。

テンプレートから構文マクロまで

テンプレートエンジンは、C ++で存在する形式であっても、かなり広範なメタプログラミング機能を提供します。 それにもかかわらず、これは、一部のASTフラグメントを他のフラグメントに置き換えるだけのシステムです。 しかし、さらに進んで、置換に加えて、他の何か、特にスクリプトを使用したASTノードでの任意のアクションの実行を許可したらどうでしょうか？ これらは、これまでで最も強力なメタプログラミングツールである構文マクロです。 プログラマーによって書かれ、メインプログラムのコンパイル段階で実行される任意のコード。コンパイラAPIおよびASTの形式でコンパイルされたプログラムの構造にアクセスし、実際には、コンパイルされたプログラムに組み込まれたコンパイラの本格的なプラグイン。 この機能を実現しているプログラミング言語は多くありません。 私の意見では最高の実装の1つはNemerle言語であるため、これをさらに詳しく検討します。

ほぼ公式のドキュメントから最も簡単な例を次に示します。

 macro TestMacro() { WriteLine("compile-time\n"); <[ WriteLine("run-time\n") ]>; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マクロ呼び出しを別のファイルに挿入する場合（これは、関数呼び出しと同じです）

 TestMacro();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイル中に、コンパイラログに「compile-time」というメッセージが表示されます。 プログラムが起動すると、コンソールに「ランタイム」というメッセージが表示されます。



ご覧のとおり、マクロは通常のコードです（この場合、メインプログラムと同じNemerle言語）。 違いは、このコードがメインプログラムのコンパイル段階で実行されることです。 したがって、コンパイルは2つのフェーズに分割されます。最初にマクロがコンパイルされ、次にメインプログラムがコンパイルされると、以前にコンパイルされたマクロを呼び出すことができます。 最初の行はコンパイル時に実行されます。 2行目には、興味深い構文-特別な括弧<[]>が含まれています。 このような角かっこを使用すると、通常の文字列と同様に、引用符で囲むかのようにコードフラグメントを取得できます。 ただし、文字列とは異なり、これらはASTフラグメントであり、インスタンス化時のテンプレートと同様に、プログラムのメイン構文ツリーに挿入されます。



また、テンプレートとは異なり、マクロは以前とは異なるコンテキスト、異なる次元にあるため、特別なブラケットが必要です。 マクロコードとマクロが動作するコードを何らかの方法で分離する必要があります。 Nemerle用語のこのような文字列は、準クォートと呼ばれます。 「準」-補間を使用してオンザフライで構築できるため-さまざまな変数の名前を特別な構文を使用して文字列に挿入し、これらの変数の値に変換する場合、スクリプト言語で書くすべての人に知られている機能。 ドキュメントの別の例：

 macro TestMacro(myName) { WriteLine("Compile-time. myName = " + myName.ToString()); <[ WriteLine("Run-time.\n Hello, " + $myName) ]>; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

引数-ASTノード（およびテンプレート用）; 準引用符にノードを挿入するには、名前の前に$記号を使用します。



もちろん、そのような文字列の代わりに、コンパイラAPIとASTノードに対応するマクロコンテキストで使用可能なタイプを使用して、挿入されたASTフラグメントを手動で構築することができました。 のようなもの

 new FunctionCall( new Literal("run-time\n") )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、「現状のまま」コードを記述し、ASTの構築作業をコンパイラに任せる方がはるかに簡単です。



Dでは、メタプログラミングはテンプレート（通常はC ++テンプレートに似ていますが、いくつかの改良点があります）とミックスインを使用して表されます。 それらをより詳細に検討しましょう。 最初のタイプはテンプレートミックスインです。 任意のコードフラグメントテンプレートを作成する機能を備えたテンプレートの同じ拡張。 たとえば、このプログラムは数値5を出力します。

 mixin template testMixin() { int x = 5; } int main(string [] argv) { mixin testMixin!(); writeln(x); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ミックスインで宣言された変数は、ミックスインがコードに含まれた後に使用可能になります。



ミックスインの2番目のタイプは、ストリングミックスインです。 この場合、mixinキーワードの引数は、Dのコードを含む行になります。

 mixin (`writeln("hello world");`);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、文字列はコンパイル時に知っている必要があります。 そして、これは、明示的に定義された定数行（そうでなければ意味をなさない）だけでなく、コンパイル時にプログラムで形成された行でもあります！ 同時に、D言語の通常の機能を使用して文字列を作成できます。これは、実行時に使用できるものと同じです。 もちろん、一定の制限はありますが、コンパイラーはコンパイル中にこれらの関数のコードを実行できる必要があります（はい、D言語自体のかなり強力なインタープリターがDコンパイラーに組み込まれています）。



文字列ミックスインの場合、準ノードとしてASTノードを使用しません。 代わりに、言語のソースコードを使用します。ソースコードは明示的に（たとえば、文字列を連結することにより）形成され、字句解析と構文解析のすべての方法を実行します。 この方法には長所と短所があります。 個人的には、ASTを使用した直接作業は、ソースコードの行を生成するよりも「クリーン」でイデオロギー的に正しいようです。 ただし、状況によっては、文字列の操作が役立つ場合があります。



また、Nimの言語について簡単に言及することもできます。 その中で、templateキーワードはDのmixinテンプレートと同様に機能します（初期のC ++スタイルのクラシックテンプレートには、別の概念が使用されます-ジェネリック）。 マクロキーワードを使用して、Nemerleマクロにやや似た構文マクロが宣言されます。 Nimはテンプレートの呼び出しの段階を形式化しようとしました-特別なプラグマを使用して、変数の名前を解決する前または後にテンプレートを呼び出すかどうかを指定できます。 Dとは異なり、ASTノードを明示的に作成できるコンパイラAPIがいくつかあります。 マクロの「衛生」の問題について触れます（マクロは、アプリケーションの時点で識別子に影響を与えないことが保証されている場合、マクロは「衛生」です...これらの問題をより詳細に検討する必要がありますが、おそらく別の時間になります）。

結論

さまざまな言語でのメタプログラミングの実装を見ると、理想的な場合のメタプログラミングの見方についていくつかの考えがあります。 ここにいくつかの考えがあります：



メタプログラミングは明示的でなければなりません



マクロの呼び出しは非常に具体的なことです（実際には非常に具体的なことです！）。また、プログラマーはコード内でそのようなマクロを一意に視覚的に識別する必要があります（構文の強調表示がなくても）。 したがって、マクロの構文は、関数の構文と明確に異なる必要があります。 多かれ少なかれ、この要件はD（ダイヤルピアでの特別なキーワードmixin）でのみ満たされます。 NemerleとNimでは、マクロは関数と区別できません。 さらに、Nemerleにはマクロを呼び出す他の方法がいくつかあります。マクロ属性と言語構文をオーバーライドする機能です。ここでは少し気を散らして、関数やクラスとは異なり構文がグローバルであることに注意してください そして、私はむしろそのような機会に否定的な態度を持っています。それは言語の侵食と言語ジェネレータへの変換につながるためです。つまり、新しいプロジェクトごとに新しい言語を学ぶ必要があります...見通しは疑わしいです）



プログラムとメタプログラムに同じ言語を使用するのはオプションです

検討したすべての例で、メタプログラム（マクロ）はメインプログラムと同じ言語で記述されています。 言語開発者は、コンパイルよりも解釈に適したマクロに別のプログラミング言語を使用する可能性について考えていなかったようです。



一方、代替アプローチの例は常に表面にあります。Webプログラミングでは、htmlマークアップ言語とjavascriptプログラミング言語が使用されます。 javascriptはhtmlレンダリング中に実行され（コンパイルアナログ）、htmlドキュメントオブジェクトモデル（HTML DOM）はスクリプトから利用可能です-ASTにかなり近いものです。 適切な関数を使用すると、HTMLソースコードの形式とDOMツリーのノードの形式の両方で、さまざまなレベルでHTML DOMノードを追加、変更、および削除できます。

 //  html   ,  mixin  D document.getElementById('myDiv').innerHTML = '<ol><li>html data</li></ol>'; //  html    ,  Nim var link = document.createElement('a'); link.setAttribute('href', 'mypage.htm'); document.getElementById('myDiv').appendChild(link);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプローチの長所と短所は何ですか？

明らかに、メタプログラムはコンパイラをクラッシュまたはサスペンドさせるべきではありません。 明らかに、ポインタやその他の低レベルのものを使用してSIでメタプログラムを記述する場合、それを終了するのは非常に簡単です。 一方、プログラムやメタプログラムで共通のコードを使用すると便利です。 この「共通コード」は、純粋なアルゴリズムのような非常に一般的なものに限定されますが、コンパイラAPIはプログラムには適用できません。「実際のOS」のライブラリ（グラフィック、ウィンドウシステム、ネットワークなど）は、メタプログラムには非常に適用できません。 もちろん、コンパイル中にいくつかのウィンドウを作成して画面に表示できますが、なぜですか？



したがって、プログラムとメタプログラムが同じ言語である必要はありません。 プログラムとメタプログラムには、完全に異なるタスクと完全に異なるランタイムがあります。 おそらく最良の解決策は、プログラマーを自由にし、いくつかの言語を使用することです：メイン言語の安全なサブセットといくつかの一般的なスクリプト言語の両方-同じjavascriptが非常に適しています。



コンパイラAPIの標準化

一部の言語での本格的なメタプログラミングの出現と普及には、必然的にコンパイラAPIの標準化が必要になります。 もちろん、これはコンパイラー自体の品質、標準への準拠、およびコンパイラー間の互換性にプラスの効果をもたらします。 そして、htmlとブラウザの例自体はかなり良いようです。 AST構造はhtmlマークアップ（一部のノードおよび他の機能の非互換性）よりも複雑ですが、そのようなAPIを構築するための基礎として、既存のメタプログラミング実装の経験と組み合わせてブラウザーテクノロジーの経験を取り入れることは素晴らしいことです。



IDEサポート

メタプログラミングは非常に複雑になる場合があります。 今まで、私が知っているすべての実装は、プログラマの仕事を促進する手段を提案していませんでした：私の心でコンパイルすることはまだアイデアです（もちろん、アマチュアがいます...）。 たとえば、C ++のメタプログラマはそれを行います。 そのため、デバッグモードとコード編集モードの両方で、特別なIDEモードでテンプレートとマクロを展開するようなツールを導入する必要があると考えています。 マクロの「コマンドライン」 REPLコードの実行に類似しています。 プログラマーは、ASTへの視覚的なアクセス、マクロの個別のコンパイルとテスト実行、「ステップごとのコンパイル」（ちょうどそのように-ステップバイステップモードでメインコードをコンパイルするときのマクロの動作を特別なデバッガーで確認するための）ツールの完全なセットを持っている必要があります



まあ、それがおそらくすべてです。 多くの疑問が舞台裏に残っていましたが、メタプログラミングの信じられないほどの力を評価するにはこれで十分だと思います。 今、これはすべてC ++になっていると想像してください。 Boostライブラリを見てください。既存のテンプレートやレキシカルマクロに対しても人々が行う驚くべき信じられないほどのことを...



もしそうだとすれば...私たちの前に本当にハッカーの機会が開かれるでしょう！