JP4346316B2

JP4346316B2 - 複数の意味レベルによるアスペクト指向プログラミングのための方法

Info

Publication number: JP4346316B2
Application number: JP2003006816A
Authority: JP
Inventors: オーランピングジョン
Original assignee: Xerox Corp
Current assignee: Xerox Corp
Priority date: 2002-01-16
Filing date: 2003-01-15
Publication date: 2009-10-21
Anticipated expiration: 2023-01-15
Also published as: US7140007B2; JP2003233499A; US20030149959A1

Description

【０００１】
【発明の属する技術分野】
本発明は、汎用の意味不変コンストラクト言語を使用したアスペクト指向プログラミングのための方法およびシステムに関する。
【０００２】
【従来の技術】
現在、複雑なソフトウェア・システムを構成する際の主要な概念は、オブジェクト指向プログラミング・パラダイムである。オブジェクト指向プログラミングの背後にある考え方は、ソフトウェア・システムをクラス、オブジェクト、メソッド（すなわち関数）などの小さなモジュラー・ユニットに細分するものである。コンパイル時、オブジェクト指向プログラミングで使用される各モジュラー・ユニットは、別々のコード・ブロックにおよそ対応する。これらのコード・ブロックは他のブロックの構造に関係なく実行されるので、不要な冗長な演算がしばしば生じる。したがって、メソッド同士が「話す」ことができれば、ソフトウェア・システムの速度全体を向上させることができる。時間に依存する大きなソフトウェア・システムの中には、メソッド同士が「話す」ことから大きな利益を得ることができるものがある。
【０００３】
アスペクト指向プログラミングでは、プログラマは、オブジェクト指向プログラミングと同様に、抽象化および分解を用いて大きな問題をより小さい管理可能な下位部分に分割することができる。ただし、問題は、関数に基づく分解ではなくアスペクトに基づく分解に従って細分する。アスペクトは、メソッド間の「会話」を容易にする。さらに、アスペクト同士が「話す」または横断することができ、その結果、横断的な実行可能プログラムが得られる。
【０００４】
【特許文献１】
米国特許第５，８８２，５９３号
【０００５】
【発明が解決しようとする課題】
既存の様々な汎用アスペクト指向プログラミング技法によれば、基本プログラムの演算をインターセプトおよび調停することが可能である。しかし、これらの技法は、オブジェクトまたはメソッドの基本レベルで現在利用可能なプログラム・データの限られた同じ視点によって制限される点で、制約を受ける。アスペクトには、１つまたは複数のオブジェクトのプログラム・データに関して、基本レベルで利用可能な情報よりも多くの情報へのアクセスを必要とするものもある。
【０００６】
以上に示したアスペクト指向プログラミングの例のコンテキストでは、アスペクトの目的およびその要件に循環があるせいで、望まれる多くの実装形態で、従来のアスペクト指向プログラミング技法の実施に明白な困難があることは明らかである。すなわち、特定のアスペクトは、そのアスペクトが必要とするデータを得るための計算にアクセスする必要がある。しかし、アスペクト自体が計算に影響を及ぼす。言い換えれば、アスペクトは、その演算を実施するために、アスペクトがそれに対して後で何をするかによって少なくとも部分的に決定されることになるオブジェクトまたはモジュールによって何かを見る必要がある。
【０００７】
【課題を解決するための手段】
オブジェクトがオブジェクト指向プログラム中の独特のコード・セットであるのと同様に、「アスペクト」は、アスペクト指向プログラム中の独特のコード・セットである。本発明によるシステム、メソッド、およびアスペクト指向プログラミング言語環境の、様々な例示的実施形態では、アスペクトは、１段階で計算結果を調べる。このアスペクトは、後続の計算段階だけに影響を及ぼし、したがって循環は存在しない。
【０００８】
本発明の一つの側面に係る方法は、データ処理デバイスを操作する命令にコンパイル可能なプログラミング要素であってプログラミング言語の式により記述された少なくとも１つの部分を有するプログラミング要素を単純化する方法であって、プログラミング要素の単純化の各段階について定義される処理であってプログラミング要素が表す計算における前記式の役割に関する情報に対する処理を表すプロパゲータの記述を含むプログラミング要素を記憶したメモリを参照可能なコンピュータが、前記メモリから読み出した前記プログラミング要素の前記少なくとも１つの部分を記述した前記式のすべてを前記プログラミング言語により定まる規則に従って書き換えることで前記プログラミング要素を単純化し、この単純化したプログラミング要素を現段階の単純化済みプログラミング要素として生成する工程と、前記プログラミング要素中に記述された前記プロパゲータの中から、前記現段階の単純化済みプログラミング要素について定義された処理を表す少なくとも１つのプロパゲータを決定する工程と、決定した前記少なくとも１つのプロパゲータが表す処理を実行することで、前記現段階の単純化済みプログラミング要素の前記少なくとも１つの部分を記述した前記式の役割に関する情報を含む少なくとも１つのプロジェクションを特定する工程と、前記特定したプロジェクションに含まれる情報と前記プログラミング言語により定まる規則とに従って、前記現段階の単純化済みプログラミング要素の前記少なくとも１つの部分を記述した式のすべてを書き換えることで、前記現段階の単純化済みプログラミング要素をさらに単純化し、この単純化したプログラミング要素を、次段階の単純化済みプログラミング要素として生成する工程と、を実行することを特徴とする。
【０００９】
【発明の実施の形態】
図１に、従来のアスペクト指向プログラミング環境１００の例示的な一実施形態を示す。図１には特に、従来のアスペクト指向プログラミング言語を使用してどのようにプログラミング要素が実行可能ソフトウェア・モジュールに変換されるかを示す。図１に示すように、１つまたは複数の高レベル・コンピュータ・プログラミング要素１２０が、アスペクト指向ウィーバ（ｗｅａｖｅｒ）１１０に提供される。アスペクト指向プログラミング環境１００内のアスペクト指向ウィーバ１１０は、高レベル・コンピュータ・プログラム要素１２０のそれぞれを１つまたは複数の実行可能モジュールにコンパイルする。アスペクト指向ウィーバ１１０は、静的と動的のいずれかとすることができる。自動アスペクト指向ウィーバ１１０は、静的な織込みプロセス（ｗｅａｖｉｎｇｐｒｏｃｅｓｓ）を実装する。静的な織込みプロセスは、クラス・ソース・コードなどの高レベル・プログラミング要素１２０中のジョイン・ポイントにアスペクト特有のステートメントを挿入することにより、このような高レベル・プログラミング要素１２０を修正する。本質的に、アスペクト指向ウィーバ１１０は、所望のアスペクト・コードをクラスにインラインする。この結果、高度に最適化された織込みコード（ｗｏｖｅｎｃｏｄｅ）が得られる。
【００１０】
図１には、汎用アスペクト指向プログラミング言語環境１００のアスペクト指向ウィーバ１１０に１つまたは複数の高レベル・プログラミング要素１２０が入力されるのが示されている。第１段階で、アスペクト指向ウィーバ１１０は、織込みコードすなわち混ざり合ったコードを生み出す。図１に示すように、高レベル・コンピュータ・プログラミング要素１２０のうちの１つからのプログラミング・ブロック１２２は、変数１２３と、変数１２３の１つまたは複数に作用する１つまたは複数のプロセスまたはメソッド１２４とに細分される。次いでアスペクト指向ウィーバ１１０は、このプログラミング・ブロック１２２を調べ、このプログラミング・ブロック１２２の様々なプロセス１２４の１つまたは複数の内部で１つまたは複数の変数１２３が重複する箇所を決定する。次いでアスペクト指向ウィーバ１１０は、コードを結合して、すなわち「織り込んで」、混ざり合ったソース・コード・ブロック１３０を生み出す。
【００１１】
織込みプロセスの第２段階で、結合したまたは織り込んだプログラム・コード・ブロック１３０を１つまたは複数の実行可能モジュール１４０にコンパイルする。図１に示すように、この第２段階では、アスペクト指向ウィーバ１１０は、織込みコード・ブロック１３０のうちの１つをとる。アスペクト指向ウィーバ１１０は、この織込みコード・ブロック１３０の織り込まれた変数１３１および織り込まれたプロセス１３３を、１つまたは複数の実行可能モジュール１４０にコンパイルする。
【００１２】
様々な例示的実施形態で、本発明によるシステムおよび方法は、エイブルソン、サスマン、サスマンによる「ＴｈｅＳｔｒｕｃｔｕｒｅａｎｄＩｎｔｅｒｐｒｅｔａｔｉｏｎｏｆＣｏｍｐｕｔｅｒＰｒｏｇｒａｍｓ」に記述されているＳｃｈｅｍｅ言語など、ラムダ算法に基づく言語に対して機能する。この言語では、基本演算は関数生成および関数適用である。関数はラムダ式で生成され、通常これは「ｌａｍｂｄａ（ｖａｒ＊）ｅｘｐ」の形式である。例えば、式「ｌａｍｂｄａ（ｘｙ）（＋（＊２ｘ）ｙ）」は、その第１の引数を２倍にしてから、２倍にした第１の引数をその第２の引数に加える関数を定義する。「ｅｘｐ」の部分はラムダ式の本体と呼ばれ、「ｖａｒ＊」の部分はその引数と呼ばれる。関数は「ｆｎａｒｇ＊」の形式の適用式によって適用されるが、「ｆｎ」は適用される関数を指し、「ａｒｇ＊」は引数である。「ｆｎ」の部分は、ラムダ式でもよく、あるいは関数を評価する式ならどんなものでもよい。計算は、ラムダ式の適用を簡約することによって継続する。ラムダ式を簡約することは一般に、それらの変数の出現にそれらの引数を代入することによって行う。
【００１３】
プログラミング言語は、式の値の考え方を中心に構築される。プログラム・モジュールは本質的に、式を値に変換することによって実行される。というのは、値はプログラム・モジュールの実行中に順に回すことができるが、式はそうすることができないからである。変数は、値を生み出す式に束縛されるのではなく、これらの値に束縛される。式が評価された後で、変数が束縛され、変数への後続の参照は、値だけにアクセスすることができる。
【００１４】
しかし本発明は、アスペクト指向プログラミングにおいて、決定または計算された値だけではなく、値がどのように計算または決定されたかに関係する他の何らかの新生エンティティが、情報のクリティカルな要素である場合があることを発見した。値の抽象化によって廃棄されるいくつかの新生エンティティがクリティカルな情報である場合があるので、関数に関数の引数の値だけを提供すれば十分であるとは限らない。
【００１５】
プログラム・ブロックに関するちょうどよい種類の情報だけを保存して、そのプログラム・ブロックに関する残りの情報は単純化する、プログラミング言語またはプログラミング言語環境が必要とされている。当然、本発明によれば、「ちょうどよい」ものは、どんなプログラム要素が情報を使用しているかに応じて異なることになる。値だけよりも多くの情報が必要とされるとき、本発明によるシステム、メソッド、およびアスペクト指向プログラミング環境は、必要とされる情報だけを提供すべきである。
【００１６】
式を評価するときは、値だけが欲しいときもあるが、より多くの情報が必要なときもある。例えば、ループの結果であるアレイだけが欲しいときもあり、アレイが特定のループまたは関数の結果であることを知ることが重要なときもある。言い換えれば、式はアレイを意味するときもあり、アレイだけよりも多くのものを意味するときもある。本発明によるシステム、方法、およびプログラミング環境では、これらのあり得る意味のそれぞれを、式の意義（ｓｉｇｎｉｆｉｃａｎｃｅ）と呼ぶ。式の値は、情報提供が最も少ない意義である。その他の意義はどれも、値によって取り込まれる情報よりも多くの情報を取り込むことになる。
【００１７】
本発明によるプログラミング・システム、方法、およびプログラミング環境は、意義の概念を、計算が作用することのできるものに変える。本発明によるプログラミング・システム、方法、およびプログラミング環境では、計算プロセスは、式をその意義のカノニカル表現になるまで単純化するものと考えることができる。当然、効率的な実装形態は、中間式をそれぞれ明示的に構築することを避けるが、このような実装形態が行う作業は、連続する中間式の間を進む作業に似ている。
【００１８】
計算の各ステップは、結果としての最終的な意義を保存するので有効である。２つの意義に違いがある場合は、この２つの意義は同じ単純化ステップを許可しないことになる。
【００１９】
本発明は、任意の２つの意義の違いが、どの計算単純化ステップがこの２つの意義によって許可されるかという点だけにあると認識するシステム、方法、およびプログラミング環境を実現する。このことは、式の意義を決定することが、その意義によって許可される計算単純化を実施することと等価であることを意味する。さらに、いくつかの意義が、より多くの情報を提供するものからより少ない情報を提供するものまで順序付けられる場合は、これらの意義を順に決定することができる。これは、まず最も多くの情報を提供する意義によって許可される単純化を実施し、次いで、次に多くの情報を提供する意義によって許可される単純化を実施し、以下同様にすることを含む。
【００２０】
個別に書かれた各ライブラリがそれ自体の意義を導入できるようにし、これらの導入された意義をそのプログラム中で使用できることが望ましいので、すべての意義に対する総合的な順序は必要ないことを理解されたい。この結果、あらゆる意義は対応する処理段階を有することになる。したがって、計算は、連続的な諸段階を通して式を単純化することに対応し、各段階は、連続的な意義の１つについての、式のカノニカル表現である。
【００２１】
本発明によるシステム、方法、およびプログラミング環境はまた、ある意義で利用可能な情報にアクセスするだけでなく、いずれかの意義に対してどの単純化を行うべきかを指定する言語コンストラクトも必要とする。さらに、どの単純化を行うべきかを決定することは、どの関数呼出しを展開すべきかを決定することを含む。後述するように、本発明によるシステムおよび方法は、どの段階で関数を簡約すべきかを指定するプログラミング形式を導入する。本質的にラムダ式は、簡約される段階まではデータ・オブジェクトのようにふるまう。簡約された時点で、ラムダ式は関数のようにふるまう。
【００２２】
他方で、意義によって提供される追加の情報は、簡約されない関数呼出し中に含まれる。この情報へは、式の意義が特定の関数の適用であるかどうかをプログラムがテストすることのできる形式によってアクセスする。式の意義は、関数のデータへのアクセス主体のようにふるまう。
【００２３】
式の意義は、式の値の決定に向けた段階なので、意義は常に、少なくとも値と同量の情報を含む。しかし、式の値の決定に向けた方向にない、式に関する他の情報にも用途がある可能性がある。これをサポートするために、本発明によるシステム、方法、およびプログラミング環境は、プロジェクションを用いてこのような情報をカプセル化する。プロジェクションは、意義に対して相対的に定義され、追加情報（通常、所与の計算の残りにおけるその意義の役割に関する）を提供する。プロジェクションの結果は値とすることができる。ただし、結果は、プロジェクションがある段階の意義とすることもできる。これは、プロジェクションが、後で総計算に組み込むことのできる計算断片を覚えていることができることを意味する。
【００２４】
式の意義は基本的にその式に局所的なものだが、プロジェクションはこれとは異なり、より大きな計算における式の役割を反映する。これは、フロー分析と同種の技法を用いてプロジェクションが計算されることを意味する。これをサポートするために、本発明によるシステム、方法、およびプログラミング環境は、「プロパゲータ」と呼ぶ機構を提供する。プロパゲータは、マッチする意義それぞれに対して実行され、そのようなマッチする意義と、そのようなマッチする意義の引数との、１つまたは複数のプロジェクションを調査および更新する。
【００２５】
プロパゲータは、上方向と下方向の両方のデータ・フローを行うことができる。上方向プロパゲータは、引数プロジェクションを調べ、式全体のプロジェクションを更新する。対照的に、下方向プロパゲータは、所与の式全体のプロジェクションを調べ、引数プロジェクションを更新する。
【００２６】
プロパゲータは更新を実施するので、特定の意義の中に埋め込まれた識別の意味を公開する。プロパゲータが所与の意義のプロジェクションを更新するとき、この更新は、同じ意義への他の参照からしか見えない。プロパゲータは意義に対して定義されるので、意義の識別が問題となる。
【００２７】
図２に示すように、本発明によるシステム、方法、およびプログラミング環境では、織込みプロセスはいくつかの段階を通して行われる。所与のプログラム要素が、連続する意義段階を通して単純化されるが、これらの段階の多くはコンパイル時に行われる。異なる程度の処理が様々な段階によって表されているが、最も単純な織込みは、２つの段階、すなわち第１段階および最終段階を生成するだけである。
【００２８】
図２に示すように、様々な例示的実施形態で、第１段階は構文段階２１０である。この構文段階２１０では、所与の高レベル・コード・ブロック１２２からの局所的情報は廃棄されておらず、コンテキスト情報は利用不可能である。これは、この高レベル・コード・ブロック１２２の元の構文に対応する。本発明によるシステム、方法、およびアスペクト指向プログラミング環境では、アスペクト指向ウィーバ１１０は、高レベル・コード・ブロック１２２から構文段階２１０を「織り込む」。構文段階２１０は、織込みコード・ブロック２２０を含む。次いで構文段階２１０は、構文段階２１０で生成した織込みコード・ブロック２２０を次の中間段階２３０に出力する。次の中間段階２３０は、アスペクト指向ウィーバ１１０によって織込みコード・ブロック２２０から織り込まれる。各段階２１０、２３０、２５０、２７０の後、段階２１０、２３０、または２５０に対応する織込みコード・ブロック２２０、２４０、または２６０中で定義された１つまたは複数のプロパゲータが実行されて、その段階２１０、２３０、または２５０で定義されるプロジェクションが決定される。次いで、これらのプロジェクションは、後続の段階２３０、２５０、および２７０でそれぞれ利用可能である。
【００２９】
図２に示すように、第１段階２１０が織り込まれた後で、第１の中間段階２３０が織り込まれる。これは、高レベル・コード・ブロック１２２に含まれるプログラム・コードをさらに最適化することにつながる。前と同様、この第１の中間段階２３０の織込みコード・ブロック２４０は、次の中間段階に入力される。最後の中間段階２５０が前の中間段階（図示せず）から織込みコード・ブロック２４５を受け取るまで、これが繰り返し行われる。
【００３０】
図２に示すように、最後の中間段階２５０で、すべての最適化織込みが完了する。この最後の中間段階２５０から出力される織込みコード・ブロック２６０が、最終織込み段階２７０に入力される。最終織込み段階２７０は、処理済み値の段階である場合が多いことを理解されたい。次いで、最終織込み段階２７０から出力される織込みコード２８０が、実行可能プログラム・モジュールに、または実行可能プログラム・モジュールのセットにコンパイルされる。
【００３１】
式が値に簡約されていないときであって、その式の適用を簡約すべきかどうかを本発明によるシステム、方法、およびプログラミング環境が知る必要があるとき、本発明によるシステム、方法、およびプログラミング環境は、その式を現段階中に簡約すべきでないと推定する。
【００３２】
プロパゲータが完全に実行されるように、プロパゲータは、プログラムまたはプログラム要素セットが中間段階にある間は、プログラムまたはプログラム要素セットと距離を置いた関係を維持する。プロパゲータは、プログラムまたはプログラム要素セットからの、意義に束縛された変数を有することになる。しかしプロパゲータは、制約された方式でしかこれらの変数を使用することができない。最初にプロパゲータは、プロパゲータが動作する段階まで論理的に実行されるが、これらの変数の束縛にはアクセスできない。すなわち、このような変数は本質的に、未束縛の変数として扱われる。次いで、プログラムまたはプログラム要素セットから、各変数が適切な意義に束縛され、プロパゲータは実行を終了する。しかし、プロパゲータは一般に、プログラムまたはプログラム要素セットに束縛された変数に後の意義を要求することができない。後の意義にアクセスしようとしても、やはりこのような変数を未束縛と見なすことになる。プロパゲータがその結果として意義を出力できるようにするために、プロパゲータは、後述する特別な形式を用いて、プロパゲータがアクセスしている意義以上に単純化すべきでないコードを囲むことができる。
【００３３】
プログラマが、様々な演算をアレイに対して実施するコードを書きたいと思っているとする。通常、プログラマは、各アレイにわたってループして新しいアレイを生み出すコードを書くことになる。プログラマは、様々なプリミティブ演算を行うルーチンを定義し、次いで、定義したプリミティブ演算を使用する高レベル演算を構築する。プログラマは、あるルーチンの出力アレイを別のルーチンの入力アレイとして使用することはしばしばある。この場合、プログラマは、融合ループを使用して結合演算を行いたい。これは、普通の関数プログラミングでは行うことができない。というのは、第２の演算を実行できるようになる前に第１の演算を実行しなければからである。ループ融合を自動的に行うオプティマイザもあるであろうが、オプティマイザは通常、不明瞭である。したがって、様々な例示的実施形態で、先に概説したシステム、方法、およびプログラミング環境を使用して、プリミティブ演算のライブラリを生み出すことができる。このライブラリ中では、演算はどのように相互と融合するかを知っており、ライブラリ・ルーチンが組み合わせて使用されるときに融合が起こる。したがって、様々な例示的実施形態で、先に概説したシステム、方法、およびプログラミング環境によれば、ライブラリ・プログラマが、ルーチンが共に融合するように定義することができる。
【００３４】
様々な例示的実施形態で、先に概説したシステム、方法、およびプログラミング環境は、ライブラリ・ルーチンがループ融合を行えるようになるにはどの機能を最低必要とするかを尋ねることにより、ループ融合に適用することができる。概して言えば、潜在的なループは、「自分の入力が、あるループによって計算されたことになる場合は、そのループの内部演算およびそれが作用したことになるアレイを与えよ。そうすれば、それを自分のループ中で使用する。」と尋ねることができる必要がある。このように言う擬似コードの例は以下のとおりである。

【００３５】
ここで、「ｐｏｉｎｔｗｉｓｅ」は、アレイにわたって関数をマッピングする関数だが、「ｐｏｉｎｔｗｉｓｅ」は、ループ融合について知っている。このケース形式は、「（ｐｔｗ−ｌｏｏｐｉｎｎｅｒ−ｆｎｉｎｎｅｒ−ａｒｇ）の形式の式によって「ａｒｇ」が計算されたことになるか？」と言っている。構文「（ｉｎｎｅｒ−ｆｎｉｎｎｅｒ−ａｒｇ）」は、パターン定数である「ｐｔｗ−ｌｏｏｐ」に対して、「ｉｎｎｅｒ−ｆｎ」および「ｉｎｎｅｒ−ａｒｇ」がパターン変数であることを示す。引数がマッチする場合は、内部ループの関数は、「ｐｏｉｎｔｗｉｓｅ」からの関数で構成されるべきである。この場合、構成された関数を使用して単一ループを実施すべきである。そうでない場合は、単純なループを使用する。具体的には、以下に示すように「ｐｔｗ−ｌｏｏｐ」を定義して、実際のループを実施することができる。

【００３６】
以下のライブラリ・コードが式と共に使用される場合は、「ｄｏｕｂｌｅ−ｐｌｕｓ」の実装は、各要素を２倍にしてから１を足す単一ループであるべきである。

【００３７】
「ｐｏｉｎｔｗｉｓｅ」の定義の鍵は、ケース・ステートメントの意味「．．．によって「ａｒｇ」が計算されたことになるか」の中の「ことになる」である。このケースは、引数を計算したことになるループをテストする必要がある。具体的には、「ｐｏｉｎｔｗｉｓｅ」は、得られるアレイまでずっと見ることなく、ループによって計算される関心のある情報を、その引数の表面的な構造を通して見ることを欲する。
【００３８】
したがって、「ｐｏｉｎｔｗｉｓｅ」は、関数とマクロとの間の何かである必要がある。具体的には、「ｐｏｉｎｔｗｉｓｅ」は、それが関心を持つ情報を見ることができるように、その引数が部分的に処理されるようにする必要がある。しかし、「ｐｏｉｎｔｗｉｓｅ」の引数が完全に評価されると、「ｐｏｉｎｔｗｉｓｅ」が関心を持つまさにその情報を除去することにつながるので、「ｐｏｉｎｔｗｉｓｅ」はそうしたくはない。したがって、様々な例示的実施形態で、先に概説した本発明によるシステム、方法、およびプログラミング環境は、これらの両極間の処理レベルを認識し、認識したこれらの処理レベルへのアクセスを提供する。
【００３９】
以下、本発明によるシステム、方法、およびプログラミング環境の基本的な形式、すなわちステートメントおよび／またはコンストラクトを示す。本発明によるシステム、方法、およびプログラミング環境の「ｃａｓｅ」ステートメントの一般的な形式は以下のとおりである。
case stage value (model (var*) exp*)* [(else exp)]
【００４０】
「ｃａｓｅ」ステートメントでは、各モデルは式である。変数は、モデル中では解放されており、式中では束縛されている。値は、連続して各モデルと比較される。値にマッチする第１のモデルでは、その式がケースの値として選択される。式はモデルの変数にアクセスすることができ、これらの変数は束縛されてマッチを形成する。
【００４１】
比較は、指定の意義の値とモデルとの間で論理的に行われる。比較は、指定の処理段階の後は行われない。また、式の単純化はゆっくりと行われる。
【００４２】
以下に示す「ｉｆ」ステートメントは、ステートメント「case value exp1 (nil ( ) exp3) (else exp2))」に対する追加の構文構造を提供する。
【００４３】
if exp1 exp2 exp3
以下に示す「ｄｅｃｏｎｓｔｒｕｃｔ」ステートメントは、ステートメント「case stage value (model (var*) exp*) (else (error))」に対する追加の構文構造を提供する。
deconstruct stage value model (var*) exp*
【００４４】
ステートメント「ｒｅｄｕｃｔｉｏｎｓｔａｇｅ」は、「ｅｘｐ」の値の呼出しを指定の段階で簡約すべきであることを指定する。
reduction-stage stage exp
【００４５】
適用ステートメントは、関数の本体がその簡約段階に達したときに簡約されることを表す。このステートメントにはキーワードがないが、単に関数「ｆｎ」を示す式で始まる。
fn exp*
【００４６】
「ｌａｍｂｄａ」ステートメントは、以下の関数を定義する。
lambda (var* [.var] [=> var]) exp*
【００４７】
形式「＝＞ｖａｒ」は、表される変数を定義される関数の結果に束縛するのに使用される。
【００４８】
ステートメント「ｓｔａｇｅ」は、段階を宣言し、宣言した段階が所与の段階よりも後であることを定義する。
stage name [:below stage]
【００４９】
ステートメント「ｐｒｏｊｅｃｔｉｏｎ」は、段階に関する情報を提供するプロジェクションを宣言する。
projection name :depends-on stage
【００５０】
ステートメント「ｐｒｏｐａｇａｔｏｒ」は、プロパゲータを生成する関数を宣言するように働く。
propagator stage [:bottom-up | :top-down] function
【００５１】
一般に、プロパゲータは、いくつかの項のプロジェクションを調べ、その他を更新することになる。プロジェクタの動作は、プロパゲータが調べたが更新はしなかったプロジェクションによって決まると仮定される。これらのプロジェクションがこの段階で動作する他のプロパゲータによって変更された場合は、このプロパゲータは再実行される。「：ｂｏｔｔｏｍ−ｕｐ」および「：ｔｏｐ−ｄｏｗｎ」のヒントは、再計算の必要を最小限に抑えるための、プロパゲータを実行する最も効率的な順番を識別する。
【００５２】
プロパゲータが見る項は、ラムダ定義、ラムダ変数、適用、およびケース形式である。ラムダ式が簡約されている場合、プロパゲータは、簡約の結果を見ることになる。これにより、プログラム・ツリーは効果的に有向グラフに変わる。具体的には、ラムダ本体の中でラムダ変数を参照した各ポイントで、実際の引数が、すべて変数使用であったものの間で共用されて現れることになる。プロパゲータからは、意義に束縛された変数が見られることはなく、意義だけしか見られないことを理解されたい。
【００５３】
ステートメント「ｕｐｄａｔｅ」は、プロパゲータの実行中だけに現れることのある形式を定義する。
update old new
【００５４】
このステートメントは、プロパゲータが適用される段階における項プロジェクションを評価すべき「ｏｌｄ」の値を、「ｎｅｗ」の値で更新する。
【００５５】
ステートメント「ｓａｍｅｆｒｅｑｕｅｎｃｙ」は、プロパゲータの実行中だけに生じることのある形式を定義する。
same-frequency exp
【００５６】
このステートメントは、式評価の頻度とプロパゲータが扱っている項の頻度が同じである場合に真を返す。
【００５７】
これが意味することの例として、以下の式を考えてみる。
(let ((x (+1 2)))
(lambda (y) (*xy))
【００５８】
「ｌｅｔ」コマンドまたは演算は、最も早い処理段階で展開されることを理解されたい。ここで、乗算項の引数の１つは、加算演算である。ラムダが介在するので、この加算演算は、乗算演算と同じ回数にわたって実行されることにはならない。プロパゲータは、これに反応できる必要がある。実行頻度が異なる場合は他に、あるケース・ブランチ中の項がケース外の変数を参照するときにも生じる。
【００５９】
別の見方では、プロパゲータがランタイムの前に実行されるので、プロパゲータの１つの呼出しが、それが処理する意義の多くの呼出しに対応することがある。これは、プロパゲータが処理するすべての下位項が主要項の呼出しごとに１度呼び出される限りは問題ではない。しかし、例が示すように、常にそうであるとは限らない。プロパゲータは、異なる頻度の意義に関連する情報を更新する際は注意する必要がある。「ｓａｍｅｆｒｅｑｕｅｎｃｙ」ステートメントは、プロパゲータがこの状況を検出する方法を提供する。
【００６０】
図３乃至５に、ループ融合を実施するためのサンプル・コード・セグメントを示す。このサンプル・コードは、あるループの結果が他のいくつかのループによって使用される場合の、すべてではないが多くを扱うものである。
【００６１】
行１〜３は、フロー処理が作用することのできる種々の情報を記述する。この情報は、単純化の最も少ないレベルにおける、式についての異なる３つの意義と項についての固有の識別子とを含む。行２は、この値をハッシュ・テーブルから得るためのキーを定義する。行３は、おそらく他にもある中でこの値を計算することになるループを定義する。共用を可能にするために、行３で定義されるプロジェクションは、このループによって計算される値のうちの１つだけについてループを保持することになる。他の値に対するプロジェクションは、このループによって計算される他の何らかの値についての（ｌｏｏｐ−ｒｅｆｅｒｅｎｃｅｖａｌｕｅ）を保持することになる。この連鎖に従うことにより、最終的にはこのループを保持する値に至る。
【００６２】
行４〜６は、トップ・レベル関数を定義する。行７〜（終わり）は、簡約されたｐｏｉｎｔｗｉｓｅ演算を定義するサブルーチン・ライブラリを定義する。行８は、トップ・レベルのラムダ式を簡約できるようにし、効果的にａｎｄ！の定義をマクロにする。行１１〜３９は、各形式をその値を計算するループで装飾するプロパゲータを定義する。行３７が実行されたときは、これは、このケースが「ｐｏｉｎｔｗｉｓｅ」でないことを示し、留意されるように出力が必要であるようにする。行３９〜４６は、値を計算するｐｏｉｎｔｗｉｓｅループを返す。これは、必要ならトリビアルなループを作ることを含む。行４３および４４は、簡約をループ融合後に簡約可能にする。行４７〜５０は、値がループによって計算された場合にそのループを返すことを示す。行５１〜５７は、引数を計算するためのループを保持するｃｏｍｐｕｔｉｎｇ−ｌｏｏｐを伴う値を返す。行５８〜６９は、結果に対するこの形式の需要を記録する。行７０〜７９は、引数に対する実際のアレイが必要とされることを示す。
【００６３】
行８０〜１００では、ｐｏｉｎｔｗｉｓｅループの構造すなわち「ｐｔｗ−ｌｏｏｐ」が、複数の値でループを生成することを含めて融合を容易にするように設計される。これを可能にするために、入力および出力にはキーで名前が付けられ、これにより、名前付けは融合の下でも変化する必要はない。これらのキーは、ループ融合時の間だけ存在する。すなわち、これらのキーは、ランタイムまでには単純化されて取り去られることになる。行９３では、ステートメント「ｆｎ」が、キー／値の対のリストと、それに対するキー／値の対の増補リストをとる。「入力」は、「ｆｎ」によって期待されるＩＤを含めた、キー／アレイの対のリストである。「出力」は、キーのリストであり、これらのキーは、ｆｎが出力するキーの中になければならない。ループは、アレイの対応要素にわたって関数をマッピングし、出力ＩＤ中の各キーに対するエントリを有するキー／アレイの対のリストを返す。行１０１〜１０３は、前段階でプロパゲータによって構築された、その結果を計算するループから、正しい結果を返すためのｐｏｉｎｔｗｉｓｅ演算を定義する。
【００６４】
行１０４〜１１７は、２つのｐｏｉｎｔｗｉｓｅループの作業を結合して行ってそれらの入力および出力を結合するループを返す。行１１５は、内部定義された関数がループ融合後に簡約可能であることを示す。行１１８〜１２５は、対のリスト中にキーがあると推定して、リスト中でキーを検索する。行１１９は、これがランタイム前に行われることを示す。行１２６および１２７は、２つのリストをマージする動作が、リスト中でＩＤを見つける動作と同様にしてコード化されることを示す。
【００６５】
ウィーバの基本動作は次のとおりである。プログラムから開始する。プログラムのすべての部分が第１段階に達するまで、プログラムを単純化する。この段階についてのプロパゲータを実行して、単純化されたプログラムをプロジェクションで装飾する。次に、プログラムのすべての部分が次の段階に達するまで、プログラムをもう少し単純化する。この単純化の間、前段階からの単純化済みプログラムと、プロパゲータによって加えられる装飾は、さらに単純化されたプログラムがどのようなものかを決定するのに利用可能なデータである。このプロセスを、プログラムの最終段階に達するまで繰り返す。プログラムの各部分は、各段階で意義を有する。問題は、プログラムのこのような部分のいずれかをある段階から次の段階まで簡約して、その部分が次の段階でその意義を正しく示すようにしなければならないかどうかである。
【００６６】
図６に、本発明によるシステム、方法、およびプログラミング環境を用いた、プログラムのコンパイル中または織込み中における図２に示した段階間の関係の例示的な一実施形態を示す。図６に示すように、１つまたは複数のプログラミング要素のセット１２０が、コンパイルされるようにアスペクト指向ウィーバ１１０に入力される。アスペクト指向ウィーバ１１０は、１つまたは複数のプログラミング要素のセット１２０に共通の変数および演算があるかどうか調べ、１つまたは複数のプログラミング要素１２０を適切な意義に簡約する命令３１０を与える。図６に示すように、１つまたは複数のプログラミング要素のセット１２０中で、３つの意義Ａ、Ｂ、Ｃが識別される。３つの意義Ａ、Ｂ、Ｃは、図２に関して先に概説した第１段階２１０に対応する第１段階の分析の結果として生成される、第１段階織込みコード・ブロック３２０に組み込まれる。
【００６７】
次に、アスペクト指向ウィーバ１１０は、プロパゲータ間可視性パス３２５に沿って命令を送ることにより、プロジェクタ３３０を呼び出す。プロジェクタ３３０は、第１段階織込みコード・ブロック３２０を調べ、意義Ａ、Ｂ、Ｃのうちのどれが次の織込み中に更新可能かを決定する。例えば、図６に示す例示的な実施形態では、プロジェクタ３３０は、意義ＡおよびＢが更新可能と識別する。プロジェクタ３３０は、意義ＡおよびＢに対する更新が未来にあればそれらを実施するために、プロジェクタ／プロパゲータ・パス３２７に沿ってプロパゲータ３３５を生み出す。次いで、アスペクト指向ウィーバ１１０は次の織込み段階に進む。
【００６８】
第２の織込み段階では、図２に関して先に概説したように、アスペクト指向ウィーバ１１０は、第１段階織込みコード・ブロック３２０を第２段階または中間段階の分析への入力として使用する。アスペクト指向ウィーバ１１０は、第１段階織込みコード・ブロック３２０を調べて、共通の変数および／または演算があれば識別し、第１段階織込みコード・ブロック３２０を適切な意義に簡約する命令３３２を送る。図６に示すように、第１段階織込みコード・ブロック３２０中で、３つの意義Ｄ、Ｅ、Ｆが識別される。３つの意義Ｄ、Ｅ、Ｆは、図２に関して先に概説した中間段階２３０に対応する第２段階の分析の結果として生成される、第２段階織込みコード・ブロック３４０に組み込まれる。
【００６９】
再びアスペクト指向ウィーバ１１０は、プロパゲータ間可視性パス３４５に沿って命令を送ることにより、プロジェクタ３５０を呼び出す。プロジェクタ３５０は、未来の織込みによってもたらされるかもしれない意義が第２段階織込みコード・ブロック３４０中にあるかどうか調べる。例えば、図６に示す例示的な実施形態では、プロジェクタ３５０は、意義Ｅがこの基準に合うと決定する。プロジェクタ３５０は、プロジェクタ／プロパゲータ・パス３４７を使用して、意義Ｅについてのプロパゲータ３５５を生み出す。次いでプロパゲータ３５５は、プロパゲータ間可視性パス３３７を使用してプロパゲータ３３５と通信して、更新すべきものがあるかどうかを決定する。この特定の例では、共通の重要性はない。すなわち、第１段階織込みコード・ブロック３２０と第２段階織込みコード・ブロック３４０の両方で継続する意義はない。したがって更新は必要ない。
【００７０】
続いて第３の織込み段階で、アスペクト指向ウィーバ１１０は、第２段階織込みコード・ブロック３４０を最後の段階の分析への入力として使用する。前述のように、アスペクト指向ウィーバ１１０は、第２段階織込みコード・ブロック３４０を調べて、共通の変数および／または演算があれば識別し、第２段階織込みコード・ブロック３４０を適切な意義に簡約する命令３４２を送る。図６に示すように、第２段階織込みコード・ブロック３４０中で、３つの意義Ａ、Ｇ、Ｈが識別される。３つの意義Ａ、Ｇ、Ｈは、図２に関して先に概説した最終段階２７０に対応する第３段階の分析の結果として生成される、第３段階織込みコード・ブロック３６０に組み込まれる。
【００７１】
次いで、アスペクト指向ウィーバ１１０は、相互運用性パス３６５に沿って命令を送ることにより、第３のプロジェクタ３７０を呼び出す。プロジェクタ３７０は、意義ＡおよびＨが更新可能と決定する。プロジェクタ３７０は、意義ＡおよびＨについてのプロパゲータ３７５を、プロジェクタ／プロパゲータ・パス３６７に沿って生み出す。次いでプロパゲータ３７５は、プロパゲータ間可視性パス３５７に沿ってプロパゲータ３５５と通信する。プロパゲータ３７５は、第２段階コード・ブロック３４０と第３段階コード・ブロック３６０との間に共通の意義がなく、更新が必要ないと決定する。
【００７２】
プロパゲータ３７５はまた、別のプロパゲータ間可視性パス３７７に沿ってプロパゲータ３３５とも通信し、第１段階織込みコード・ブロック３２０と第３段階織込みコード・ブロック３６０との間で意義Ａが共通であると決定する。次いでプロパゲータ３７５は、第１段階織込みコード・ブロック３２０および第３段階織込みコード・ブロック３６０中の、意義Ａへの参照すべてを更新する。これにより、織込みコードが後に正しく実行されることが確実になる。前述のようにこのプロセスは、すべてのコードが完全に織り込まれ、したがって完全に最適化されるまで継続する。
【００７３】
図７に、ループ融合の例についての織込みプロセスを示す。アスペクト指向ウィーバ１１０は、高レベル・プログラム・コード・ブロック４２０を読み込む命令４１０を構文段階４３０に与える。この高レベル・プログラム・コード・ブロック４２０は、織込みプロセスの第１段階すなわち構文段階４３０で第１段階コード・ブロックとして使用されるように提供される。次いで、アスペクト指向ウィーバ１１０は、構文段階４３０で第１段階コード・ブロック４２０を調べて、第１段階コード・ブロック４２０全体で共通の変数および演算を識別する。アスペクト指向ウィーバ１１０は、命令４３５を使用して構文段階４３０を制御する。この例では、構文段階４３０と最終段階４８０との間に２つの中間段階がある。構文段階４３０から出力された織込みコード・ブロック４４０は、第１の中間段階４５０に入力されるが、この例示的な実施形態では、この第１の中間段階４５０はループ構造段階と呼ぶことができる。
【００７４】
次に、アスペクト指向ウィーバ１１０は、第１段階織込みコード・ブロック４４０を調べ、ループ構造段階４５０に命令４５５を与える。ループ構造段階４５０の間の処理で、第１段階コード・ブロック４２０のループによって計算されるアレイの候補ループ構造が公開される。ループ構造段階は、第２段階織込みコード・ブロック４６０を出力する。ループ構造はアレイにわたって明示的なマッピング関数を実施するので、残念ながら、特定ループの値をループ構造段階４５０から直接計算することはできない。この状況では、ランタイム前に内部ループ関数を簡約する方が望ましい。したがって、ループ構造を簡約済みループに変形する必要がある。この変形は、計算段階４７０によって実現される。
【００７５】
続いてアスペクト指向ウィーバ１１０は、第２段階織込みコード・ブロック４６０に含まれるループ構造を簡約する命令４７５を計算段階４７０に与える。これに応答して、計算段階４７０は、第３段階織込みコード・ブロック４８０を出力する。これは、完全に織り込まれた最終的な段階である。この最終段階コード・ブロック４８０はまた、値段階コード・ブロック４８０とも呼ぶ。次いで、最終段階コード・ブロック４８０は、コンパイラ４９０に出力される。コンパイラ４９０は、信号チャネル４９５を介したアスペクト指向ウィーバ１１０の制御下で、完全に織り込まれた値段階ブロック４８０をコンパイルして、実行可能コード・ブロック５００を形成する。実行可能コード・ブロック５００は、コンパイラ４９０から出力される。
【００７６】
問題は、ライブラリがループを融合する度に、ライブラリは、その引数のループの新しい作業実行を必要とする場合があることである。引数が共用される場合、重複する計算が生じる。これに対する解決法の１つは、引数が共用される場合にはループを融合しないことである。別の解決法は、共用される引数の使用すべてを反映する単一のループを生成することである。
【００７７】
前述の解決法のいずれかを採用する場合、引数がプログラム中の他の箇所でどのように使用されるかに関する情報を知ることが必要である。すなわち、ライブラリ・コードは、その直接の引数だけでなく、より広いコンテキストに関するいくらかの情報にアクセスできる必要がある。ライブラリ・コードは、その引数に関係する何らかのデータ・フロー情報を必要とする。これには、より多くの言語機能が必要である。
【００７８】
より単純な回答を実現するには、引数が共用されるなら融合しない場合に、ライブラリ・コードは、「自分に渡されようとしている引数が他の箇所でも使用されるか？」といったように尋ねる必要がある。この質問には、どの段階かにかかわらず、単にその引数を計算するコードを見るだけでは回答できないことを理解されたい。この質問への回答は、引数がどのように計算されるかではなく、どのように使用されるかにある。さらに、この質問への回答は、引数識別の認識、すなわち、同じ引数が他の箇所で使用されることが意味するものの認識に依拠する。
【００７９】
したがって、これをサポートするために、様々な例示的実施形態で、先に概説したシステム、方法、およびプログラミング環境は、項プロジェクションの概念をサポートする。プロジェクションは、項に関する情報を提供する。この情報は通常、項自体からは入手不可能だがその使用のコンテキストからは入手可能な情報である。したがって、様々な例示的実施形態で、先に概説したシステム、方法、およびプログラミング環境は、プロジェクション・コンテキスト情報を計算するために、別のコンストラクトとして前述のプロパゲータを導入する。プロパゲータは、適切な段階の項と照合され、次いで項または項の下位項のプロジェクションに関する情報を公開することができる形式である。最初、プロジェクションの値は、項が空のコンテキスト中で見られることを意味するデフォルトに設定される。プロパゲータが実行される中で、プロパゲータはコンテキストのピクチャを埋める。したがってプロパゲータは、命令的にコード化される間、項のコンテキストに関する限界をインクリメンタルに上げるように動作する。
【００８０】
以下の擬似コードは、項が２回以上使用されるかどうかを計算する。

【００８１】
この例が機能するようにするには、新しい段階として、ループ融合段階の前に実施される動作段階を導入する必要がある。ループの結合である「ｄｏｕｂｌｅ」のような定義は、この段階で簡約され、それにより、ループ結果の使用が見えるようになる。このようにすれば、長い範囲のフロー分析は必要ない。問題となるのはプログラマが関心を持つプロシージャだけなので、いくつかのプロシージャを通して１つの形式に従う必要はない。ループ構造決定時に形式構造へのアクセスを有するプロシージャが、それを直接受け取るプロシージャである。
【００８２】
ただし、この機構は、長い範囲のフロー分析を実施することもできる。これは、途中で情報を蓄積してプロパゲートすることによって行う。実際、この機構は、図２および６に関して先に論じたような、共有の第２の手法すなわち単一の大きな融合ループの生成を表すのに十分なものである。
【図面の簡単な説明】
【図１】プログラミング間の従来の関係を示す図である。
【図２】本発明のシステムおよび方法による、意味ベースのアスペクト指向プログラミング環境でプログラミング要素の様々な段階によって表される種々の処理程度の例示的な一実施の形態である。
【図３】本発明によるシステムおよび方法を用いてループ融合を達成するためのプログラムの例示的な擬似コード・リストである（図３乃至５でひとつの疑似コード・リストを示す）。
【図４】本発明によるシステムおよび方法を用いてループ融合を達成するためのプログラムの例示的な擬似コード・リストである（図３乃至５でひとつの疑似コード・リストを示す）。
【図５】本発明によるシステムおよび方法を用いてループ融合を達成するためのプログラムの例示的な擬似コード・リストである（図３乃至５でひとつの疑似コード・リストを示す）。
【図６】図２に示した段階間の関係の例示的な一実施の形態をより詳細に示す図である。
【図７】本発明のシステムおよび方法による意味ベースのアスペクト指向プログラミング環境をループ融合動作に適用したときの例示的な一結果を示す図である。
【符号の説明】
１１０アスペクト指向ウィーバ、１２０プログラミング要素、１２２高レベル・コード・ブロック、２１０構文段階（第１段階）、２２０，２４０，２４５，２６０織込みコード・ブロック、２３０第１の中間段階、２５０最後の中間段階、２７０最終織込み段階、３２０第１段階織込みコード・ブロック、３２５，３３７，３４５，３７７プロパゲータ間可視性パス、３２７，３４７，３６７プロジェクタ／プロパゲータ・パス、３３０，３５０，３７０プロジェクタ、３３５，３５５，３７５プロパゲータ、３４０第２段階織込みコード・ブロック、３６０第３段階織込みコード・ブロック、３６５相互運用性パス、４２０第１段階コード・ブロック、４３０構文段階、４５０第１の中間段階、ループ構造段階、４４０第１段階織込みコード・ブロック、４６０第２段階織込みコード・ブロック、４７０計算段階、４８０最終段階コード・ブロック、第３段階織込みコード・ブロック、値段階コード・ブロック、４９０コンパイラ、４９５信号チャネル、５００実行可能コード・ブロック。

Claims

データ処理デバイスを操作する命令にコンパイル可能なプログラミング要素であってプログラミング言語の式により記述された少なくとも１つの部分を有するプログラミング要素を単純化する方法であって、
プログラミング要素の単純化の各段階について定義される処理であってプログラミング要素が表す計算における前記式の役割に関する情報に対する処理を表すプロパゲータの記述を含むプログラミング要素を記憶したメモリを参照可能なコンピュータが、
前記メモリから読み出した前記プログラミング要素の前記少なくとも１つの部分を記述した前記式のすべてを前記プログラミング言語により定まる規則に従って書き換えることで前記プログラミング要素を単純化し、この単純化したプログラミング要素を現段階の単純化済みプログラミング要素として生成する工程と、
前記プログラミング要素中に記述された前記プロパゲータの中から、前記現段階の単純化済みプログラミング要素について定義された処理を表す少なくとも１つのプロパゲータを決定する工程と、
決定した前記少なくとも１つのプロパゲータが表す処理を実行することで、前記現段階の単純化済みプログラミング要素の前記少なくとも１つの部分を記述した前記式の役割に関する情報を含む少なくとも１つのプロジェクションを特定する工程と、
前記特定したプロジェクションに含まれる情報と前記プログラミング言語により定まる規則とに従って、前記現段階の単純化済みプログラミング要素の前記少なくとも１つの部分を記述した式のすべてを書き換えることで、前記現段階の単純化済みプログラミング要素をさらに単純化し、この単純化したプログラミング要素を、次段階の単純化済みプログラミング要素として生成する工程と、を実行することを特徴とする方法。
プログラミング言語の式により記述されたプログラミング要素を、データ処理デバイスを操作する命令にコンパイル可能な複数の織込みコード・ブロックに変換する方法であって、
前記プログラミング要素を記憶したメモリを参照可能なコンピュータが、
（ａ）前記メモリから読み出した前記プログラミング要素を記述した複数の式の間で、少なくとも１つの共通の変数と少なくとも１つの共通のプロセスとのうちの少なくとも１つを識別する工程と、
（ｂ）識別した、少なくとも１つの共通の変数と少なくとも１つの共通のプロセスとのうちの少なくとも１つに関する前記プログラミング要素中の記述を、前記プログラミング言語により定まる規則に従って書き換え、この書き換えられた記述を前記プログラミング要素の少なくとも１つの意義として特定する工程と、
（ｃ）前記少なくとも１つの意義の記述を含む前記プログラミング要素のコード・ブロックを第１の織込みコード・ブロックとして生成する工程と、
（ｄ）前記第１の織込みコード・ブロックが表す計算に基づいて、前記第１の織込みコード・ブロックに含まれる前記意義のうち、前記方法の後続のステップで更新可能なものを０個、１個、または複数決定する工程と、
（ｅ）決定の結果に基づいて、第１の織込みコード・ブロックの決定された更新可能な意義に対して任意の所望の更新を実施する処理を表すプロパゲータを呼び出す工程と、
工程（ａ）〜（ｅ）を少なくとも１回繰り返して、直前に生成された織込みコード・ブロックに基づいて後の織込みコード・ブロックを生成する工程と、
（ｆ）前に生成された少なくとも１つの織込みコード・ブロックのプロパゲータと後の織込みコード・ブロックのプロパゲータとが表す処理を実行することで、前記前に生成された少なくとも１つの織込みコード・ブロックの意義のいずれかが後の織込みコード・ブロックと共通かどうかを決定する工程と、
（ｇ）少なくとも１つの後の織込みコード・ブロックおよび前に生成された少なくとも１つの織込みコード・ブロック中で、後の織込みコード・ブロックと前記前に生成された少なくとも１つの織込みコード・ブロックとに共通の意義があれば、当該共通の意義を有する織込みコード・ブロックのそれぞれのプロパゲータが表す処理に従って当該共通の意義を更新する工程と、を実行することを特徴とする方法。