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

Abstract

(57)【要約】 【課題】 複数の意味レベルによるアスペクト指向プロ
グラミングの方法を提供する。 【解決手段】 アスペクトには、１つまたは複数のオブ
ジェクトのプログラム・データに関して、基本レベルで
利用可能な情報よりも多くの情報へのアクセスを必要と
するものがある。アスペクト指向プログラミング・シス
テム、方法、および環境のアスペクトは、１段階で計算
結果を調べる。このアスペクトは、後続の計算段階だけ
に影響を及ぼし、したがって循環は存在しない。また、
局所的または大域的なカスタム・フロー分析を各段階で
実施して、非局所的な情報をプロパゲートすることもで
きる。コード・ブロックを操作することではなく、様々
な計算段階の結果を操作することからみてプログラミン
グを容易にすることができるので、「マクロ」スタイル
のプログラミングを削減または回避することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、汎用の意味不変コ
ンストラクト言語を使用したアスペクト指向プログラミ
ングのための方法およびシステムに関する。

【０００２】

【従来の技術】現在、複雑なソフトウェア・システムを
構成する際の主要な概念は、オブジェクト指向プログラ
ミング・パラダイムである。オブジェクト指向プログラ
ミングの背後にある考え方は、ソフトウェア・システム
をクラス、オブジェクト、メソッド（すなわち関数）な
どの小さなモジュラー・ユニットに細分するものであ
る。コンパイル時、オブジェクト指向プログラミングで
使用される各モジュラー・ユニットは、別々のコード・
ブロックにおよそ対応する。これらのコード・ブロック
は他のブロックの構造に関係なく実行されるので、不要
な冗長な演算がしばしば生じる。したがって、メソッド
同士が「話す」ことができれば、ソフトウェア・システ
ムの速度全体を向上させることができる。時間に依存す
る大きなソフトウェア・システムの中には、メソッド同
士が「話す」ことから大きな利益を得ることができるも
のがある。

【０００３】アスペクト指向プログラミングでは、プロ
グラマは、オブジェクト指向プログラミングと同様に、
抽象化および分解を用いて大きな問題をより小さい管理
可能な下位部分に分割することができる。ただし、問題
は、関数に基づく分解ではなくアスペクトに基づく分解
に従って細分する。アスペクトは、メソッド間の「会
話」を容易にする。さらに、アスペクト同士が「話す」
または横断することができ、その結果、横断的な実行可
能プログラムが得られる。

【０００４】

【特許文献１】米国特許第５，８８２，５９３号

【０００５】

【発明が解決しようとする課題】既存の様々な汎用アス
ペクト指向プログラミング技法によれば、基本プログラ
ムの演算をインターセプトおよび調停することが可能で
ある。しかし、これらの技法は、オブジェクトまたはメ
ソッドの基本レベルで現在利用可能なプログラム・デー
タの限られた同じ視点によって制限される点で、制約を
受ける。アスペクトには、１つまたは複数のオブジェク
トのプログラム・データに関して、基本レベルで利用可
能な情報よりも多くの情報へのアクセスを必要とするも
のもある。

【０００６】以上に示したアスペクト指向プログラミン
グの例のコンテキストでは、アスペクトの目的およびそ
の要件に循環があるせいで、望まれる多くの実装形態
で、従来のアスペクト指向プログラミング技法の実施に
明白な困難があることは明らかである。すなわち、特定
のアスペクトは、そのアスペクトが必要とするデータを
得るための計算にアクセスする必要がある。しかし、ア
スペクト自体が計算に影響を及ぼす。言い換えれば、ア
スペクトは、その演算を実施するために、アスペクトが
それに対して後で何をするかによって少なくとも部分的
に決定されることになるオブジェクトまたはモジュール
によって何かを見る必要がある。

【０００７】

【課題を解決するための手段】オブジェクトがオブジェ
クト指向プログラム中の独特のコード・セットであるの
と同様に、「アスペクト」は、アスペクト指向プログラ
ム中の独特のコード・セットである。本発明によるシス
テム、メソッド、およびアスペクト指向プログラミング
言語環境の、様々な例示的実施形態では、アスペクト
は、１段階で計算結果を調べる。このアスペクトは、後
続の計算段階だけに影響を及ぼし、したがって循環は存
在しない。

【０００８】本発明の一つの側面によれば、データ処理
デバイスを操作する命令にコンパイル可能なプログラミ
ング要素を単純化する方法であって、プログラミング要
素が少なくとも１つの部分を有し、前記方法が、プログ
ラミング要素を、その少なくとも１つの部分がすべて第
１段階に達するまで単純化して、現段階の単純化済みプ
ログラミング要素を生み出す工程と、現段階の単純化済
みプログラミング要素について少なくとも１つのプロパ
ゲータを決定することであって、プロパゲータがプログ
ラミング要素中に記述される工程と、決定した少なくと
も１つのプロパゲータを使用して、少なくとも１つのプ
ロジェクションを現段階の単純化済みプログラミング要
素に関連付ける工程と、現段階の単純化済みプログラミ
ング要素および関連するプロジェクションに少なくとも
部分的に基づいて、現段階の単純化済みプログラミング
要素を、その少なくとも１つの部分がすべて次の段階に
達するまで単純化して、次段階の単純化済みプログラミ
ング要素を生み出す工程とを含む。

【０００９】

【発明の実施の形態】図１に、従来のアスペクト指向プ
ログラミング環境１００の例示的な一実施形態を示す。
図１には特に、従来のアスペクト指向プログラミング言
語を使用してどのようにプログラミング要素が実行可能
ソフトウェア・モジュールに変換されるかを示す。図１
に示すように、１つまたは複数の高レベル・コンピュー
タ・プログラミング要素１２０が、アスペクト指向ウィ
ーバ（ｗｅａｖｅｒ）１１０に提供される。アスペクト
指向プログラミング環境１００内のアスペクト指向ウィ
ーバ１１０は、高レベル・コンピュータ・プログラム要
素１２０のそれぞれを１つまたは複数の実行可能モジュ
ールにコンパイルする。アスペクト指向ウィーバ１１０
は、静的と動的のいずれかとすることができる。自動ア
スペクト指向ウィーバ１１０は、静的な織込みプロセス
（ｗｅａｖｉｎｇ ｐｒｏｃｅｓｓ）を実装する。静的
な織込みプロセスは、クラス・ソース・コードなどの高
レベル・プログラミング要素１２０中のジョイン・ポイ
ントにアスペクト特有のステートメントを挿入すること
により、このような高レベル・プログラミング要素１２
０を修正する。本質的に、アスペクト指向ウィーバ１１
０は、所望のアスペクト・コードをクラスにインライン
する。この結果、高度に最適化された織込みコード（ｗ
ｏｖｅｎ ｃｏｄｅ）が得られる。

【００１０】図１には、汎用アスペクト指向プログラミ
ング言語環境１００のアスペクト指向ウィーバ１１０に
１つまたは複数の高レベル・プログラミング要素１２０
が入力されるのが示されている。第１段階で、アスペク
ト指向ウィーバ１１０は、織込みコードすなわち混ざり
合ったコードを生み出す。図１に示すように、高レベル
・コンピュータ・プログラミング要素１２０のうちの１
つからのプログラミング・ブロック１２２は、変数１２
３と、変数１２３の１つまたは複数に作用する１つまた
は複数のプロセスまたはメソッド１２４とに細分され
る。次いでアスペクト指向ウィーバ１１０は、このプロ
グラミング・ブロック１２２を調べ、このプログラミン
グ・ブロック１２２の様々なプロセス１２４の１つまた
は複数の内部で１つまたは複数の変数１２３が重複する
箇所を決定する。次いでアスペクト指向ウィーバ１１０
は、コードを結合して、すなわち「織り込んで」、混ざ
り合ったソース・コード・ブロック１３０を生み出す。

【００１１】織込みプロセスの第２段階で、結合したま
たは織り込んだプログラム・コード・ブロック１３０を
１つまたは複数の実行可能モジュール１４０にコンパイ
ルする。図１に示すように、この第２段階では、アスペ
クト指向ウィーバ１１０は、織込みコード・ブロック１
３０のうちの１つをとる。アスペクト指向ウィーバ１１
０は、この織込みコード・ブロック１３０の織り込まれ
た変数１３１および織り込まれたプロセス１３３を、１
つまたは複数の実行可能モジュール１４０にコンパイル
する。

【００１２】様々な例示的実施形態で、本発明によるシ
ステムおよび方法は、エイブルソン、サスマン、サスマ
ンによる「Ｔｈｅ Ｓｔｒｕｃｔｕｒｅ ａｎｄ Ｉｎ
ｔｅｒｐｒｅｔａｔｉｏｎ ｏｆ Ｃｏｍｐｕｔｅｒ
Ｐｒｏｇｒａｍｓ」に記述されているＳｃｈｅｍｅ言語
など、ラムダ算法に基づく言語に対して機能する。この
言語では、基本演算は関数生成および関数適用である。
関数はラムダ式で生成され、通常これは「ｌａｍｂｄａ
（ｖａｒ＊）ｅｘｐ」の形式である。例えば、式「ｌａ
ｍｂｄａ（ｘｙ）（＋（＊２ｘ）ｙ）」は、その第１の
引数を２倍にしてから、２倍にした第１の引数をその第
２の引数に加える関数を定義する。「ｅｘｐ」の部分は
ラムダ式の本体と呼ばれ、「ｖａｒ＊」の部分はその引
数と呼ばれる。関数は「ｆｎａｒｇ＊」の形式の適用式
によって適用されるが、「ｆｎ」は適用される関数を指
し、「ａｒｇ＊」は引数である。「ｆｎ」の部分は、ラ
ムダ式でもよく、あるいは関数を評価する式ならどんな
ものでもよい。計算は、ラムダ式の適用を簡約すること
によって継続する。ラムダ式を簡約することは一般に、
それらの変数の出現にそれらの引数を代入することによ
って行う。

【００１３】プログラミング言語は、式の値の考え方を
中心に構築される。プログラム・モジュールは本質的
に、式を値に変換することによって実行される。という
のは、値はプログラム・モジュールの実行中に順に回す
ことができるが、式はそうすることができないからであ
る。変数は、値を生み出す式に束縛されるのではなく、
これらの値に束縛される。式が評価された後で、変数が
束縛され、変数への後続の参照は、値だけにアクセスす
ることができる。

【００１４】しかし本発明は、アスペクト指向プログラ
ミングにおいて、決定または計算された値だけではな
く、値がどのように計算または決定されたかに関係する
他の何らかの新生エンティティが、情報のクリティカル
な要素である場合があることを発見した。値の抽象化に
よって廃棄されるいくつかの新生エンティティがクリテ
ィカルな情報である場合があるので、関数に関数の引数
の値だけを提供すれば十分であるとは限らない。

【００１５】プログラム・ブロックに関するちょうどよ
い種類の情報だけを保存して、そのプログラム・ブロッ
クに関する残りの情報は単純化する、プログラミング言
語またはプログラミング言語環境が必要とされている。
当然、本発明によれば、「ちょうどよい」ものは、どん
なプログラム要素が情報を使用しているかに応じて異な
ることになる。値だけよりも多くの情報が必要とされる
とき、本発明によるシステム、メソッド、およびアスペ
クト指向プログラミング環境は、必要とされる情報だけ
を提供すべきである。

【００１６】式を評価するときは、値だけが欲しいとき
もあるが、より多くの情報が必要なときもある。例え
ば、ループの結果であるアレイだけが欲しいときもあ
り、アレイが特定のループまたは関数の結果であること
を知ることが重要なときもある。言い換えれば、式はア
レイを意味するときもあり、アレイだけよりも多くのも
のを意味するときもある。本発明によるシステム、方
法、およびプログラミング環境では、これらのあり得る
意味のそれぞれを、式の意義（ｓｉｇｎｉｆｉｃａｎｃ
ｅ）と呼ぶ。式の値は、情報提供が最も少ない意義であ
る。その他の意義はどれも、値によって取り込まれる情
報よりも多くの情報を取り込むことになる。

【００１７】本発明によるプログラミング・システム、
方法、およびプログラミング環境は、意義の概念を、計
算が作用することのできるものに変える。本発明による
プログラミング・システム、方法、およびプログラミン
グ環境では、計算プロセスは、式をその意義のカノニカ
ル表現になるまで単純化するものと考えることができ
る。当然、効率的な実装形態は、中間式をそれぞれ明示
的に構築することを避けるが、このような実装形態が行
う作業は、連続する中間式の間を進む作業に似ている。

【００１８】計算の各ステップは、結果としての最終的
な意義を保存するので有効である。２つの意義に違いが
ある場合は、この２つの意義は同じ単純化ステップを許
可しないことになる。

【００１９】本発明は、任意の２つの意義の違いが、ど
の計算単純化ステップがこの２つの意義によって許可さ
れるかという点だけにあると認識するシステム、方法、
およびプログラミング環境を実現する。このことは、式
の意義を決定することが、その意義によって許可される
計算単純化を実施することと等価であることを意味す
る。さらに、いくつかの意義が、より多くの情報を提供
するものからより少ない情報を提供するものまで順序付
けられる場合は、これらの意義を順に決定することがで
きる。これは、まず最も多くの情報を提供する意義によ
って許可される単純化を実施し、次いで、次に多くの情
報を提供する意義によって許可される単純化を実施し、
以下同様にすることを含む。

【００２０】個別に書かれた各ライブラリがそれ自体の
意義を導入できるようにし、これらの導入された意義を
そのプログラム中で使用できることが望ましいので、す
べての意義に対する総合的な順序は必要ないことを理解
されたい。この結果、あらゆる意義は対応する処理段階
を有することになる。したがって、計算は、連続的な諸
段階を通して式を単純化することに対応し、各段階は、
連続的な意義の１つについての、式のカノニカル表現で
ある。

【００２１】本発明によるシステム、方法、およびプロ
グラミング環境はまた、ある意義で利用可能な情報にア
クセスするだけでなく、いずれかの意義に対してどの単
純化を行うべきかを指定する言語コンストラクトも必要
とする。さらに、どの単純化を行うべきかを決定するこ
とは、どの関数呼出しを展開すべきかを決定することを
含む。後述するように、本発明によるシステムおよび方
法は、どの段階で関数を簡約すべきかを指定するプログ
ラミング形式を導入する。本質的にラムダ式は、簡約さ
れる段階まではデータ・オブジェクトのようにふるま
う。簡約された時点で、ラムダ式は関数のようにふるま
う。

【００２２】他方で、意義によって提供される追加の情
報は、簡約されない関数呼出し中に含まれる。この情報
へは、式の意義が特定の関数の適用であるかどうかをプ
ログラムがテストすることのできる形式によってアクセ
スする。式の意義は、関数のデータへのアクセス主体の
ようにふるまう。

【００２３】式の意義は、式の値の決定に向けた段階な
ので、意義は常に、少なくとも値と同量の情報を含む。
しかし、式の値の決定に向けた方向にない、式に関する
他の情報にも用途がある可能性がある。これをサポート
するために、本発明によるシステム、方法、およびプロ
グラミング環境は、プロジェクションを用いてこのよう
な情報をカプセル化する。プロジェクションは、意義に
対して相対的に定義され、追加情報（通常、所与の計算
の残りにおけるその意義の役割に関する）を提供する。
プロジェクションの結果は値とすることができる。ただ
し、結果は、プロジェクションがある段階の意義とする
こともできる。これは、プロジェクションが、後で総計
算に組み込むことのできる計算断片を覚えていることが
できることを意味する。

【００２４】式の意義は基本的にその式に局所的なもの
だが、プロジェクションはこれとは異なり、より大きな
計算における式の役割を反映する。これは、フロー分析
と同種の技法を用いてプロジェクションが計算されるこ
とを意味する。これをサポートするために、本発明によ
るシステム、方法、およびプログラミング環境は、「プ
ロパゲータ」と呼ぶ機構を提供する。プロパゲータは、
マッチする意義それぞれに対して実行され、そのような
マッチする意義と、そのようなマッチする意義の引数と
の、１つまたは複数のプロジェクションを調査および更
新する。

【００２５】プロパゲータは、上方向と下方向の両方の
データ・フローを行うことができる。上方向プロパゲー
タは、引数プロジェクションを調べ、式全体のプロジェ
クションを更新する。対照的に、下方向プロパゲータ
は、所与の式全体のプロジェクションを調べ、引数プロ
ジェクションを更新する。

【００２６】プロパゲータは更新を実施するので、特定
の意義の中に埋め込まれた識別の意味を公開する。プロ
パゲータが所与の意義のプロジェクションを更新すると
き、この更新は、同じ意義への他の参照からしか見えな
い。プロパゲータは意義に対して定義されるので、意義
の識別が問題となる。

【００２７】図２に示すように、本発明によるシステ
ム、方法、およびプログラミング環境では、織込みプロ
セスはいくつかの段階を通して行われる。所与のプログ
ラム要素が、連続する意義段階を通して単純化される
が、これらの段階の多くはコンパイル時に行われる。異
なる程度の処理が様々な段階によって表されているが、
最も単純な織込みは、２つの段階、すなわち第１段階お
よび最終段階を生成するだけである。

【００２８】図２に示すように、様々な例示的実施形態
で、第１段階は構文段階２１０である。この構文段階２
１０では、所与の高レベル・コード・ブロック１２２か
らの局所的情報は廃棄されておらず、コンテキスト情報
は利用不可能である。これは、この高レベル・コード・
ブロック１２２の元の構文に対応する。本発明によるシ
ステム、方法、およびアスペクト指向プログラミング環
境では、アスペクト指向ウィーバ１１０は、高レベル・
コード・ブロック１２２から構文段階２１０を「織り込
む」。構文段階２１０は、織込みコード・ブロック２２
０を含む。次いで構文段階２１０は、構文段階２１０で
生成した織込みコード・ブロック２２０を次の中間段階
２３０に出力する。次の中間段階２３０は、アスペクト
指向ウィーバ１１０によって織込みコード・ブロック２
２０から織り込まれる。各段階２１０、２３０、２５
０、２７０の後、段階２１０、２３０、または２５０に
対応する織込みコード・ブロック２２０、２４０、また
は２６０中で定義された１つまたは複数のプロパゲータ
が実行されて、その段階２１０、２３０、または２５０
で定義されるプロジェクションが決定される。次いで、
これらのプロジェクションは、後続の段階２３０、２５
０、および２７０でそれぞれ利用可能である。

【００２９】図２に示すように、第１段階２１０が織り
込まれた後で、第１の中間段階２３０が織り込まれる。
これは、高レベル・コード・ブロック１２２に含まれる
プログラム・コードをさらに最適化することにつなが
る。前と同様、この第１の中間段階２３０の織込みコー
ド・ブロック２４０は、次の中間段階に入力される。最
後の中間段階２５０が前の中間段階（図示せず）から織
込みコード・ブロック２４５を受け取るまで、これが繰
り返し行われる。

【００３０】図２に示すように、最後の中間段階２５０
で、すべての最適化織込みが完了する。この最後の中間
段階２５０から出力される織込みコード・ブロック２６
０が、最終織込み段階２７０に入力される。最終織込み
段階２７０は、処理済み値の段階である場合が多いこと
を理解されたい。次いで、最終織込み段階２７０から出
力される織込みコード２８０が、実行可能プログラム・
モジュールに、または実行可能プログラム・モジュール
のセットにコンパイルされる。

【００３１】式が値に簡約されていないときであって、
その式の適用を簡約すべきかどうかを本発明によるシス
テム、方法、およびプログラミング環境が知る必要があ
るとき、本発明によるシステム、方法、およびプログラ
ミング環境は、その式を現段階中に簡約すべきでないと
推定する。

【００３２】プロパゲータが完全に実行されるように、
プロパゲータは、プログラムまたはプログラム要素セッ
トが中間段階にある間は、プログラムまたはプログラム
要素セットと距離を置いた関係を維持する。プロパゲー
タは、プログラムまたはプログラム要素セットからの、
意義に束縛された変数を有することになる。しかしプロ
パゲータは、制約された方式でしかこれらの変数を使用
することができない。最初にプロパゲータは、プロパゲ
ータが動作する段階まで論理的に実行されるが、これら
の変数の束縛にはアクセスできない。すなわち、このよ
うな変数は本質的に、未束縛の変数として扱われる。次
いで、プログラムまたはプログラム要素セットから、各
変数が適切な意義に束縛され、プロパゲータは実行を終
了する。しかし、プロパゲータは一般に、プログラムま
たはプログラム要素セットに束縛された変数に後の意義
を要求することができない。後の意義にアクセスしよう
としても、やはりこのような変数を未束縛と見なすこと
になる。プロパゲータがその結果として意義を出力でき
るようにするために、プロパゲータは、後述する特別な
形式を用いて、プロパゲータがアクセスしている意義以
上に単純化すべきでないコードを囲むことができる。

【００３３】プログラマが、様々な演算をアレイに対し
て実施するコードを書きたいと思っているとする。通
常、プログラマは、各アレイにわたってループして新し
いアレイを生み出すコードを書くことになる。プログラ
マは、様々なプリミティブ演算を行うルーチンを定義
し、次いで、定義したプリミティブ演算を使用する高レ
ベル演算を構築する。プログラマは、あるルーチンの出
力アレイを別のルーチンの入力アレイとして使用するこ
とはしばしばある。この場合、プログラマは、融合ルー
プを使用して結合演算を行いたい。これは、普通の関数
プログラミングでは行うことができない。というのは、
第２の演算を実行できるようになる前に第１の演算を実
行しなければからである。ループ融合を自動的に行うオ
プティマイザもあるであろうが、オプティマイザは通
常、不明瞭である。したがって、様々な例示的実施形態
で、先に概説したシステム、方法、およびプログラミン
グ環境を使用して、プリミティブ演算のライブラリを生
み出すことができる。このライブラリ中では、演算はど
のように相互と融合するかを知っており、ライブラリ・
ルーチンが組み合わせて使用されるときに融合が起こ
る。したがって、様々な例示的実施形態で、先に概説し
たシステム、方法、およびプログラミング環境によれ
ば、ライブラリ・プログラマが、ルーチンが共に融合す
るように定義することができる。

【００３４】様々な例示的実施形態で、先に概説したシ
ステム、方法、およびプログラミング環境は、ライブラ
リ・ルーチンがループ融合を行えるようになるにはどの
機能を最低必要とするかを尋ねることにより、ループ融
合に適用することができる。概して言えば、潜在的なル
ープは、「自分の入力が、あるループによって計算され
たことになる場合は、そのループの内部演算およびそれ
が作用したことになるアレイを与えよ。そうすれば、そ
れを自分のループ中で使用する。」と尋ねることができ
る必要がある。このように言う擬似コードの例は以下の
とおりである。 (define pointwise (lambda (fn arg) (case arg ((ptw-loop inner-fn inner-arg) (inner-fn inner-arg) (ptw-loop (lambda (x) (fn (inner-fn x))) inner-arg)) (else (ptw-loop fn arg)))))

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

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

【００３７】「ｐｏｉｎｔｗｉｓｅ」の定義の鍵は、ケ
ース・ステートメントの意味「．．．によって「ａｒ
ｇ」が計算されたことになるか」の中の「ことになる」
である。このケースは、引数を計算したことになるルー
プをテストする必要がある。具体的には、「ｐｏｉｎｔ
ｗｉｓｅ」は、得られるアレイまでずっと見ることな
く、ループによって計算される関心のある情報を、その
引数の表面的な構造を通して見ることを欲する。

【００３８】したがって、「ｐｏｉｎｔｗｉｓｅ」は、
関数とマクロとの間の何かである必要がある。具体的に
は、「ｐｏｉｎｔｗｉｓｅ」は、それが関心を持つ情報
を見ることができるように、その引数が部分的に処理さ
れるようにする必要がある。しかし、「ｐｏｉｎｔｗｉ
ｓｅ」の引数が完全に評価されると、「ｐｏｉｎｔｗｉ
ｓｅ」が関心を持つまさにその情報を除去することにつ
ながるので、「ｐｏｉｎｔｗｉｓｅ」はそうしたくはな
い。したがって、様々な例示的実施形態で、先に概説し
た本発明によるシステム、方法、およびプログラミング
環境は、これらの両極間の処理レベルを認識し、認識し
たこれらの処理レベルへのアクセスを提供する。

【００３９】以下、本発明によるシステム、方法、およ
びプログラミング環境の基本的な形式、すなわちステー
トメントおよび／またはコンストラクトを示す。本発明
によるシステム、方法、およびプログラミング環境の
「ｃａｓｅ」ステートメントの一般的な形式は以下のと
おりである。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 (2)

【特許請求の範囲】
1. 【請求項１】 データ処理デバイスを操作する命令にコ
   ンパイル可能なプログラミング要素を単純化する方法で
   あって、プログラミング要素が少なくとも１つの部分を
   有し、前記方法が、 プログラミング要素を、その少なくとも１つの部分がす
   べて第１段階に達するまで単純化して、現段階の単純化
   済みプログラミング要素を生み出す工程と、 現段階の単純化済みプログラミング要素について少なく
   とも１つのプロパゲータを決定することであって、プロ
   パゲータがプログラミング要素中に記述される工程と、 決定した少なくとも１つのプロパゲータを使用して、少
   なくとも１つのプロジェクションを現段階の単純化済み
   プログラミング要素に関連付ける工程と、 現段階の単純化済みプログラミング要素および関連する
   プロジェクションに少なくとも部分的に基づいて、現段
   階の単純化済みプログラミング要素を、その少なくとも
   １つの部分がすべて次の段階に達するまで単純化して、
   次段階の単純化済みプログラミング要素を生み出す工程
   とを含むことを特徴とする方法。
2. 【請求項２】 プログラミング要素を、データ処理デバ
   イスを操作する命令にコンパイル可能な複数の織込みコ
   ード・ブロックに変換する方法であって、 （ａ）プログラミング要素中で、少なくとも１つの共通
   の変数と少なくとも１つの共通のプロセスとのうちの少
   なくとも１つを識別する工程と、 （ｂ）識別した、少なくとも１つの共通の変数と少なく
   とも１つの共通のプロセスとのうちの少なくとも１つに
   基づいて、プログラミング要素を少なくとも１つの意義
   に簡約する工程と、 （ｃ）少なくとも１つの意義を第１の織込みコード・ブ
   ロックに組み込むこと、 （ｄ）組み込んだ意義のうち、方法の後続のステップで
   更新可能なものを０個、１個、または複数決定する工程
   と、 （ｅ）決定の結果に基づいて、第１の織込みコード・ブ
   ロックの決定された更新可能な意義に対して任意の所望
   の更新を実施するのに使用できるプロパゲータを呼び出
   す工程と、 工程（ａ）〜（ｅ）を少なくとも１回繰り返して、直前
   に生み出された織込みコード・ブロックに基づいて後の
   織込みコード・ブロックを生み出す工程とを含み、さら
   に、 （ｆ）前に生み出された少なくとも１つの織込みコード
   ・ブロックのプロパゲータと通信して、前記前に生み出
   された少なくとも１つの織込みコード・ブロックの意義
   のいずれかが後の織込みコード・ブロックと共通かどう
   かを決定する工程と、および （ｇ）少なくとも１つの後の織込みコード・ブロックお
   よび前に生み出された少なくとも１つの織込みコード・
   ブロック中で、後の織込みコード・ブロックと前記前に
   生み出された少なくとも１つの織込みコード・ブロック
   とに共通の意義があればそれを更新する工程とを含むこ
   とを特徴とする方法。