JP5966801B2 - 言語変換装置、プログラム - Google Patents

Description

本発明は、関数型言語で記述されたプログラムを関数型言語処理に不向きな演算処理装置において実行可能な形に変換する言語変換装置等に関する。

プログラマブルコントローラ（ＰＬＣ：Programmable Logic Controller）の制御プログラムを関数型のプログラム構造で表した関数型制御言語（ＦＣＬ：Functional Control Language；尚、関数型言語という場合もあるものとする）が使用されている。

ＦＣＬについては特許文献１，特許文献２等で説明されているが、ここで簡単にＦＣＬについて説明する。ＦＣＬは、一つの機能を図１０に示す形式の関数式で表し、更に図１１の図上上側に示すように関数式自身を別の関数式の引数とすることができるものである。従って、図１１の図上下側に示すように言語の２次元的な表現（２次元構造ツリー表現）を行う事ができ、記述性が高くなる。これより、例えば、図１２に示すような、ＰＬＣプログラムの表現依存部と機械依存部をつなぐ中間言語としての役割を果たすことができる。

関数型言語の実行方式として命令スタックとデータスタックを用いて演算を実行する方式がある（上記特許文献１，２や特許文献３など）。
しかし、上記方式により演算を行うには、命令スタックとデータスタックという構成が必要となり、これらの構成と備えない装置では実行が困難、または、前記方式をエミュレーションするため性能が低下するという問題があった。その問題を解決するために、関数型言語を手続型言語に変換して、手続型言語（たとえばＣ言語）で実行する方式が提案されていた（特許文献４）。

特許文献４では、例えば図１１の図上上側に示す関数型言語の関数式を、図１３に示すような配列にして、これに基づいて図１４に示すような二次元構造（ツリー構造）を生成し、このツリー構造に基づいて手続型言語プログラムへの変換を行うものである、
図１４に示すツリー構造は、図１３に示す配列順に従って、順次、この配列の各要素から図１４に示す各ノードを生成していくことで作成される。図１４に示す各ノードは、“ノードの名称”、“インスタンス名”、“子供ノードへのポインタ”、“次のノードへのポインタ”の各データ項目から成る。

“ノードの名称”には、配列の要素に格納されている関数またはオペランド等が格納される。尚、「開き括弧“（”＋任意の名称）」の形式のものが関数であり、それ以外は（閉じ括弧を除いて）オペランド（変数など）である。また、配列の要素が閉じ括弧“）”である場合には、ノードを生成することなく、この閉じ括弧に対応する開き括弧のノードに処理対象を戻す。“インスタンス名”は、リーフ以外のノードに付与される、ツリー構造内におけるノード識別子である。尚、リーフとは子供ノードを持たないノード（末端のノード）である。

また、尚、以下の説明では、各ノードをその“ノードの名称”を用いて区別して記述する場合があるものとする。例えば、“ノードの名称”が“（Ａ”であるノードは、ノード“（Ａ”等と呼ぶものとする。

ここで、関数は、別の関数およびオペランド（変数など）を引数とすることができる。関数のノードからその引数のノードをポイント（リンク）するときは、“子供ノードへのポインタ”に、リンクの為のポインタを設定する。つまり、呼び出し元の関数のノードにおける“子供ノードへのポインタ”に、その引数のノード（複数ある場合には何れか１つ）を指定するためのポインタ値を設定する。

一方、呼び出し元の関数のノードが同一である引数のノード（複数ノード）には、“次ノードへのポインタ”に所定のポインタ値を設定することで、自分に続く引数を指定する。

図１４に示す例では、例えば、ノード“（Ｂ”における“子供ノードへのポインタ”には、その引数ノードの１つである“ｖ”ノードを指定（リンク）するポインタが格納されている。更に、関数Ｂの引数はｖとｗであるので、“ｖ”ノードの“次ノードへのポインタ”には、自ノードに続く引数のノードである“ｗ”ノードを指定（リンク）するポインタが格納されている。

そして、図１４に示すツリー構造に基づいて、図１１の図上上側に示す関数型言語のプログラムを、手続型言語プログラム（不図示；尚、後述する図１５（ａ）に示す例については、図１５（ｂ）に一例を示してある）へ変換する。

この変換処理は、図１４に示すツリー構造から“子供ノードがリーフしかないノード”（該当ノードというものとする）を見つける毎に、該当ノードの関数とその子供ノードの引数などから、該当ノードのインスタンス名を代入先とする代入文（命令文）を生成する。これが手続型言語プログラムである。そして、該当ノードの子供ノードを全て削除する。これを、ノードが１つになるまで繰り返す。

特開平０１−２９８４４４号公報 特開平０２−２３０４２６号公報 特開平０１−２４３１２６号公報 特開２０１２−１０４０６５号公報

ここで、上記特許文献４の発明では、上述した従来技術の問題を解消するものであるが、下記の課題がある。
関数型言語は全ての関数に値を持ち、関数の引数に関数を記述することが可能であるため、条件分岐（たとえばIF〜THEN〜ELSE〜END_IF）を行ない、その結果をさらに、条件に用いる記述を簡単に行うことが可能である。

例として条件分岐がネスト（入れ子）になったＦＣＬプログラム（図１５（ａ））と、このＦＣＬプログラムを従来手法によって手続型言語プログラムに変換したもの（図１５（ｂ））とを示す。尚、図１５（ａ）は、PASCAL言語による記述例とした（代入を”：＝”で示し、関数呼び出しを”Function(a, b, …)”で示す）が、言語はPASCAL言語に限るわけではない。

尚、図１５（ｂ）中でfuncGt, funcSub, funcIf, funcEq, funcMulは、ＦＣＬプログラムの(＞,(−,(IF,(＝,(＊関数に対応する、変換先の手続型言語における関数等を表現したものである。

また、尚、図１５（ｂ）の例は、図示の通り、１０行程度の命令文（代入文）から成る。各命令文は、基本的には、各変換対象ノード毎に、変換対象ノードに係る関数について、該変換対象ノードの各子供ノードに係る各オペランドまたは識別子を引数として用いて、該変換対象ノードの識別子（インスタンス名）を代入先とする命令文である。

ここで、条件分岐処理は、実行条件によって選択された一方の式（THEN部またはELSE部）だけが実行されるべきであるのに対して、本変換結果においては、THEN部とELSE部の両方を実行し、その結果を選択（funcIf部）する処理になってしまい、余計な処理実行を行うという問題が発生する。また、その実行結果を保存しておくために余分な一時変数を設ける必要があり、変換後のプログラム実行環境を圧迫（メモリの使用量増加）してしまう。実際に図１５（ｂ）では１０個の変数と１０の実行文が必要である。

尚、上記課題は、上記条件分岐がネスト（入れ子）になる例に限らず、条件分岐を含むプログラムの場合に生じることになる。
本発明の課題は、関数型制御言語プログラムを手続型言語プログラムに変換することができ、命令スタックとデータスタックを待たない手続き形の命令処理を行うことができると共に、特に条件分岐を有する関数型制御言語プログラムについて、関数型制御言語の条件分岐命令を適切な構文に変換することができ、余分な実行や一時変数を作成することもなく効率的な実行が実現できる言語変換装置、プログラム等を提供することである。

本発明の言語変換装置は、関数型言語で記述された制御処理プログラムを、手続型の命令処理を行う装置で実行可能な言語形式のプログラムである手続型言語プログラムに変換する言語変換装置において、前記関数型言語で記述された制御処理プログラムにおける関数／オペランドの各要素の配列を記憶した関数型言語記憶手段と、前記配列の各要素を順次取得し、該各要素に応じたノードと該ノード間のリンクから成るツリー構造を生成するツリー構造作成手段と、前記ツリー構造中のノードは、子供ノードを持たないノードであるリーフと、該リーフ以外のノードである子持ノードとから成り、該ツリー構造中の各ノードのうち該子持ノードにユニークな識別子を付与すると共に、条件分岐の関数に係わるノードの子供ノードには、同一の識別子を付与する識別子付与手段と、前記識別子を付与後の前記ツリー構造の各ノードに基づいて前記手続型言語への変換を行う手段であって、変換対象ノードが前記条件分岐の関数に係わるノードである場合には、予め登録されている条件分岐処理に係る所定の雛形を用いて前記手続型言語プログラムの生成を行う変換手段とを有する。

上記構成の言語変換装置において、例えば、前記所定の雛形は、ｉｆ〜ｔｈｅｎ〜ｅｌｓｅ文であり、前記変換手段は、前記条件分岐の関数に係わるノードの各子供ノードに係わる前記手続型言語への変換結果を、前記所定の雛形の該当箇所に当て嵌めることで、前記手続型言語プログラムの生成を行う。

ｉｆ〜ｔｈｅｎ〜ｅｌｓｅ文であれば、条件分岐結果に応じてｔｈｅｎとｅｌｓｅの何れか一方しか実行されないので、上述した余分な実行が生じるという課題を解消できる。
上記構成の言語変換装置において、例えば、前記識別子は、前記手続型言語における代入先とし、前記識別子付与手段によって前記同一の識別子の付与が行われていることによって、前記ｔｈｅｎに係る前記代入先と、前記ｅｌｓｅに係る前記代入先とに、同一の識別子が用いられる。

上記ｔｈｅｎとｅｌｓｅのどちらが実行されても、代入先となる変数名（識別子）は同一（共通使用）であるので、実行結果を保存しておくための一時変数が少なくて済み、上述した変換後のプログラム実行環境を圧迫する課題を解消できる。

本発明の言語変換装置、プログラム等によれば、関数型制御言語プログラムを手続型言語プログラムに変換することができ、命令スタックとデータスタックを待たない手続型の命令処理を行うことができると共に、特に条件分岐を有する関数型制御言語プログラムについて、関数型制御言語の条件分岐命令を適切な構文に変換することができ、余分な実行や一時変数を作成することもなく効率的な実行が実現できる。

本例の言語変換装置の構成・機能ブロック図である。 図１５（ａ）のＦＣＬプログラム例に対応する配列である。 図２の例に応じて従来手法で生成される二次元構造（ツリー）例である。 図２の例に応じて本手法で生成される二次元構造（ツリー）例である。 本手法によるプログラム変換結果例を示す図である。 本例の言語変換装置の処理の全体フローチャート図である。 本例の言語変換装置の処理の詳細フローチャート図（その１）である。 本例の言語変換装置の処理の詳細フローチャート図（その２）である。 本例の言語変換装置の処理の詳細フローチャート図（その３）である。 関数型制御言語の基本構造を示す図である。 関数型制御言語を二次元構造を表現したものである。 関数型制御言語の位置付けを示す図である。 図１１の例に応じた配列の一例である。 図１１、図１３の例に応じた二次元構造ツリーの一例である。 （ａ）は条件分岐がネストになったＦＣＬプログラムの一例、（ｂ）はこのＦＣＬプログラムを従来手法によって手続型言語に変換したものである。

以下、図面を参照して本発明の実施の形態について説明する。
図１は、本例の言語変換装置の構成・機能ブロック図である。
図示の本例の言語変換装置１０によれば、関数型制御言語（ＦＣＬ）を手続型言語（Ｃ言語など）に変換することができ、命令スタックとデータスタックを待たない手続き形の命令処理を行うことができると共に、特に条件分岐を有するＦＣＬプログラム等について、ＦＣＬの条件分岐命令を適切な構文に変換することができ、余分な処理実行を行うことが無くなり、余分な一時変数を作成することもなく、効率的な実行が実現できるようにすることが可能となる。

図１に示す例の言語変換装置１０は、関数型言語（ＦＣＬ）格納部１１、二次元構造（ツリー）変換部１２、二次元構造格納部１３、関数名−インスタンス名作成部１４、インスタンス名管理部１５、命令並び換え部（変換部）１６、手続型言語格納部１７の各機能部を有する。

尚、関数名−インスタンス名作成部１４とインスタンス名管理部１５とを、まとめて“識別子付与部”と呼ぶものとしてもよい。“識別子付与部”は、ツリー構造中の各ノードのうち、リーフ以外のノードにユニークな識別子を付与すると共に、条件分岐の関数に係わるノードの子供ノードには（例えば、各子供ノードのうちの一部に（例えば３つのうちの２つに））、同一の識別子を付与するものである。

言語変換装置１０は、例えば汎用のパソコンやサーバ装置等で実現されるので、特に図示しないが、ＣＰＵ、記憶装置（ハードディスク等）、メモリ、入力部、表示部、通信部等の一般的なコンピュータ装置の構成を有している。

上記不図示の記憶装置には、予め所定のアプリケーションプログラムが記憶されており、上記ＣＰＵがこのアプリケーションプログラムを読出し・実行することにより、上記各種機能部の処理機能が実現される。すなわち、関数型言語（ＦＣＬ）格納部１１、二次元構造（ツリー）変換部１２、二次元構造格納部１３、関数名−インスタンス名作成部１４、インスタンス名管理部１５、命令並び換え部１６、手続型言語格納部１７等は、上記ＣＰＵが上記アプリケーションプログラムを読出し・実行することにより実現される。

また、本発明は、上記言語変換装置１０の形態に限らず、その各種機能をコンピュータ等により実現させる為の上記アプリケーションプログラム自体として構成することもできる。

尚、これらの各種機能部のうち、関数型言語（ＦＣＬ）格納部１１、二次元構造（ツリー）変換部１２、「関数名−インスタンス名作成部」１４は、上記従来の特許文献４における、関数型言語（ＦＣＬ）格納装置１１、二次元構造（ツリー）変換部１２、関数名−インスタンス名作成部１４と同じであっても構わない。また、二次元構造格納部１３は、生成された二次元構造（ツリー構造）を格納するという点では、特許文献４の二次元構造格納装置１３と略同様であってよいが、格納内容は異なる。また、手続型言語格納部１７も、手続型言語に変換したプログラムを格納するという点では、特許文献４の手続型言語格納装置１６と略同様であってよいが、格納内容は異なる。

上述したことから、本例の言語変換装置１０は、例えば一例としては、特許文献４の言語変換装置に対して、インスタンス名管理部１５が追加されると共に、命令並び換え部１６の処理内容が異なるものと見做すこともできるが、この例に限るものではない。

関数型言語（ＦＣＬ）格納部１１は、関数型言語の任意のプログラム（ＦＣＬプログラム）を格納するものであり、更にこのＦＣＬプログラムの命令（関数）／オペランド（変数など）等の各要素を配列として格納したものである。ここでは、ＦＣＬプログラムの一例として上記図１５（ａ）に示した例を用いるものとするならば、このプログラム例に対応する上記配列は、図２に示すものとなる。このような配列生成自体は、例えば上記図１３に示すように従来より行われていたものであり、ここでは特に説明しない。

二次元構造（ツリー）変換部１２と「関数名−インスタンス名作成部」１４は、上記の通り既存の機能であってよく、二次元構造（ツリー）変換部１２は、上記関数型言語（ＦＣＬ）格納部１１に格納された上記配列に基づいて、ＦＣＬプログラムを例えば上記図１４に示したような二次元構造（ツリー構造）表現で表したデータ（二重の親子関係を持ったリンク構造である）を生成する。

また、「関数名−インスタンス名作成部」１４は、上記ツリー構造の末端部（リーフ）以外のノード（子持ノードと呼ぶものとする）に対して、ツリー内でのユニークなノード識別子（本例ではインスタンス名とするがこの例に限らない）を付与するものである。

上記図２に示した例に対しては、特許文献４の従来手法の場合には図３に示すツリー構造が生成されることになる。但し、本例では、更にインスタンス名管理部１５によって複数のノードに同一のインスタンス名が付与される場合があり、その結果、二次元構造格納部１３には、図４に示すツリー構造が生成・格納されることになる。尚、上述したように、リーフとは子供ノードを持たないノード（末端のノード）である。

尚、上記ツリー構造は、上記配列の各要素（関数やオペランド等）を順次読み出して各要素に応じたノードを生成すると共に、ノード間のリンク（ポインタなど）を生成することで作成される（詳細は特許文献４など参照；尚、特許文献４における図５のＳ７の処理とＳ８の処理とを逆にしてもよい）。

ここで、ノードにおける“子供ノードへのポインタ”と“次のノードへのポインタ”について簡単に説明する。まず、基本的に、「（ＩＦ」等のような開き括弧“（”で始まる要素については（つまり、関数については）、閉じ括弧“）”までがその引数となるので、閉じ括弧“）”の次の要素に係るノードが“次のノード”ということになる。また、上記引数となるノードは全て子供ノードとなるが、そのうちの最初のノードのみが“子供ノードへのポインタ”によってポイント（リンク）されることになる。

一方、開き括弧“（”も閉じ括弧“）”も無い要素のノードについては（つまり、オペランドのノードについては）、その子供ノードは存在しない。よって、その“子供ノードへのポインタ”は常にＮＵＬＬが設定される。

尚、本説明では、関数に応じたノードは関数ノード、オペランド（変数など）に応じたノードを変数ノードと呼ぶ場合もあるものとする。
図３と図４とを比較すれば明らかなように、両者の相違はインスタンス名である。すなわち、図３に示すように（そして、特許文献４に記載のように）、従来ではインスタンス名はユニークな存在であり、従って複数のノードに同一のインスタンス名が付与されるようなことはない。これに対して、図４に示すように、本例の場合、複数のノードに同一のインスタンス名が付与されることも有り得る。

例えば、図３においては、図上中央付近の「ノード名称が“（−”」である２つのノードのインスタンス名は、一方が“INST_5”、他方が“INST_6”となっている。これに対して、図４におけるこれら２つのノードのインスタンス名は、両方とも“INST_5”となっている。

これは、インスタンス名管理部１５によって、所定の条件に該当する複数のノードに対して同一のインスタンス名が付与されるものである（例えば、インスタンス名付与処理中において、条件分岐（ＩＦ等）の関数に係るノードを検出した場合、その子供ノードのうちの２つのノードに、同一のインスタンス名を付与する場合がある）。インスタンス名管理部１５は、例えば、条件分岐の関数（ＩＦ等）の関数ノードがあった場合には、例えば、その子供ノードのうちの２番目のノードと３番目のノードに対して、同一のインスタンス名を付与するようにする。

尚、上記のような二次元構造のデータを表すためには、本データ構造だけである、ＸＭＬ（Extensible Markup Language）で記述されたテキストによるデータ構造であってもよい。ＸＭＬであれば、ツリー構造データの追加／削除／検索などの操作手段の作成は容易である。

命令並び換え部１６は、基本的には特許文献４の命令並び換え部１５と略同様の処理を行うものであってもよいが、更に、条件分岐に関しては後述する処理を行うものであり、それによって例えば図５に示すプログラムを生成するものである。詳しくは後述する。

手続型言語格納部１７には、命令並び換え部１６によって生成された手続型言語のプログラム（例えば図５に示すもの）が格納される。
以下、上述した各種機能部について、具体例も参照しながら、更に詳細に説明する。

まず、上記二次元構造（ツリー）変換部１２及び関数名−インスタンス名作成部１４による二次元構造（ツリー構造）生成処理について、以下、説明する。尚、これらは上記の通り既存技術であってよいので、簡単に説明するものとする。また、具体例として、上述した図１５（ａ）に示すプログラム例を用いる。

既に述べたように、特許文献４の場合と略同様に、二次元構造（ツリー）変換部１２は、関数型言語（ＦＣＬ）格納部１１に格納されているプログラム（ＦＣＬプログラムという）から、ツリー構造を生成する。これは、例えば、ＦＣＬプログラムの内容（配列）をそのままツリー構造化する。この時、例えば、関数部を親の節（ノード）、引数部を子供のノードにする。例えば、図１５（ａ）に示すＦＣＬプログラム例の場合、まず図２に示す配列を生成し、この配列に基づいて図３に示すツリー構造を生成する。

この様なツリー構造生成処理については、特許文献４に記載されているが、以下、簡単に説明するものとする。
二次元構造（ツリー）変換部１２は、関数型言語（ＦＣＬ）格納部１１に格納される上記配列の各要素（本例ではＦＣＬコード）を順次読み出して、上記ツリー構造を生成する（但し、未だインスタンス名は無い）。本処理は、例えば特許文献４に記載のように、関数開始子（開き括弧“（”）、関数終了子（閉じ括弧“）”）、オペランド（括弧以外）等に基づいて、例えば下記の手法により実現できる。

つまり、最初にルートノード（一番上位の要素：処理を再帰的に実行する為のダミーノード）を作成し、“現在処理中ノード”として記録する。そして、配列のＦＣＬコードを順次読み出して、基本的には、それが関数またはオペランドであるならば（換言すれば、閉じ括弧以外であるならば）、それに対応するノードを新規生成すると共に、この新規ノードとそのときの上記“現在処理中ノード”との間のリンク（ポインタ）を生成する。これは、“子供ノードへのポインタ”または“次のノードへのポインタ”によってリンクする。そして、新規ノードを新たな上記“現在処理中ノード”とする。

つまり、配列から取得した要素（ＦＣＬコードなど）が任意の関数である場合には、該関数の名称を“ノード名称”とするノードを新規作成すると共に、現在処理中ノードから該新規ノードをポイントするポインタを、該現在処理中ノードにおける“子供ノードへのポインタ”または“次のノードへのポインタ”の何れかに設定し、更に、該新規ノードを新たな前記現在処理中ノードとする。

また、配列から取得した要素が任意のオペランドである場合には、該オペランドの名称を“ノード名称”とするノードを新規作成すると共に、現在処理中ノードから該新規ノードをポイントするポインタを、該現在処理中ノードにおける“子供ノードへのポインタ”または“次のノードへのポインタ”の何れかに設定し、更に、該新規ノードにおける“子供ノードへのポインタ”を無効化し、更に、該新規ノードを新たな前記現在処理中ノードとする。

尚、上記配列から読み出したＦＣＬコードが上記閉じ括弧である場合には、上記の通りノードを作成しないと共に、この場合には上記“現在処理中ノード”を、当該閉じ括弧に対応する開き括弧（関数）のノードに設定する。

上記“現在処理中ノード”から新規ノードへのポインタは、“現在処理中ノード”における上記“子供ノードへのポインタ”と“次のノードへのポインタ”の何れかに格納される。例えば特許文献４に記載のように、変数ノードの“子供ノードへのポインタ”には常にＮＵＬＬが格納される。従って、“現在処理中ノード”が変数ノードである場合には、常に、その“次のノードへのポインタ”に上記新規ノードへのポインタが格納される。

一方、“現在処理中ノード”が変数ノードである場合には、最初の新規ノードに関しては“子供ノードへのポインタ”にこの新規ノードへのポインタが格納され、２番目の新規ノードがある場合には“次のノードへのポインタ”にこの新規ノードへのポインタが格納される。換言すれば、“子供ノードへのポインタ”にポインタ設定済みであれば“次のノードへのポインタ”に新規ノードへのポインタを設定し、そうでければ“子供ノードへのポインタ” に新規ノードへのポインタを設定する。

尚、“子供ノードへのポインタ”が示すノードは、文字通り、そのノードの子供ノードである。また、“次のノードへのポインタ”が示すノードは、そのノードと親ノードが同一である他のノードである。例えば、図３に示すインスタンス名がINST_4、INST_5、INST_6の３つのノードの親ノードは、全て同じである（何れも、INST_3のノードが親ノード）。

例えば、図３において、図示の上の真ん中に示す“（＞”のノード（INST_4）が“現在処理中ノード”である場合、図上その右側に示す“ａ”のノードが新規ノードとして作成され、これによって“（＞”のノードの“子供ノードへのポインタ”に、“ａ”のノードへのポインタが格納される（尚、図上では、この様なポインタを矢印で示している）。また、“ａ”のノードは変数ノードであるので、その“子供ノードへのポインタ”にＮＵＬＬが格納される。

次に、“ａ”のノードが新たな“現在処理中ノード”となり、その右側の“ｂ”のノードが新規ノードとして作成され、これによって“現在処理中ノード”（“ａ”のノード）の“次のノードへのポインタ”に、“ｂ”のノードへリンクするポインタが格納される。また、“ｂ”のノードは変数ノードであるので、その“子供ノードへのポインタ”にＮＵＬＬが格納される。

そして、次に読み出されるＦＣＬコードは閉じ括弧“）”であるので、“現在処理中ノード”（“ｂ”のノード）の“次のノードへのポインタ”にＮＵＬＬが格納されると共に、この閉じ括弧“）”に対応する開き括弧“（”のノード（“（＞”のノード（INST_4））が（換言すれば、“現在処理中ノード”の親ノードが）、新たな“現在処理中ノード”となる。

この状態で、次に読み出されるＦＣＬコードは“（−”であるので、図示の“（−”のノード（INST_5）が新規作成されると共に、“現在処理中ノード”（“（＞”のノード）の“次のノードへのポインタ”に、当該“（−”のノードへリンクするポインタが格納されることになる。そして、当該“（−”のノードが、新たな“現在処理中ノード”となる。

他のノードも上記一例と略同様にして作成され、それによって図２の配列に対しては従来手法の場合には図３に示すツリー構造が生成されることになる。
尚、ＮＵＬＬの設定方法は、一例を上記したが、他の例については特許文献４に記載されており、ここでは省略する。尚、図３、図４において、斜線がＮＵＬＬを意味している。よって、例えば図上右上角に示す“ｂ”のノードの場合には、“インスタンス名”、“子供ノードへのポインタ”、“次のノードへのポインタ”の３つの項目にＮＵＬＬが設定されていることになる。

「関数名−インスタンス名作成部」１４は、上記ツリー構造の末端部（リーフ）以外のノードに対して、ツリー内でのユニークなノード識別子（本例ではインスタンス名）を付与する。リーフは具体的な変数オペランドとなるので、そのままにする。

換言すれば、「関数名−インスタンス名作成部」１４は、各関数ノードに対して、順次、ユニークな（重複しない）名称／記号／番号等を生成・付与する。本例では”INST_”を接頭辞としたシリアル番号を割り付けている。割り付け順序は、関数ノードの出現順序である。換言すれば、「関数名−インスタンス名作成部」１４だけの場合には、各ノードは全て異なるインスタンス名が割り付けられることになり、複数のノードに同一のインスタンス名が割り付けられるようなことはない。

ここで、上記「関数名−インスタンス名作成部」１４によるインスタンス名の割り付け処理の際に、インスタンス名管理部１５によって、所定の条件に該当する複数のノードがある場合には、当該複数のノードに同一のインスタンス名を割り当てる。

上記所定の条件とは、第一に、親ノードが条件分岐であるノード、換言すれば条件分岐ノードの子供ノードであることである。この第一の条件に加えて、更に条件があるが、これについては後述する。

換言すれば、インスタンス名管理部１５は、ノードに記述された関数が条件分岐などである場合（値を持たない構文に対する関数である場合）に、分岐して実行する内容に対して同一のインスタンスが割り当てられるように、インスタンス名の管理を行う（条件によりどちらか一方しか実行しない為、条件によらず実行結果を同一のインスタンス変数に格納する）。

命令並び換え部１６は、二次元構造格納部１３に格納されたツリー構造の先頭から末端に向かう方向に順次辿って、子供ノードがリーフしかないノードを検索する。この検索の結果として、子供ノードがリーフしかないノードが検出される毎に、当該子供ノードがリーフしかないノードについて、ノードに記述された関数が呼び出されて、その関数の値を代入する代入文が、代入先をそのノードのインスタンス名（インスタンス変数というものとする）として作成されて、手続型言語格納部１７に格納される。そして、上記処理で手続型言語格納部１７に格納したノードの子供ノードがすべて削除される。これらの処理を、ツリー構造上のノードの数が１つになるまで繰り返し実行する。

関数型言語の命令（関数）／変数（オペランド）の各要素の配列から生成されたツリー構造を用いて、ネストされた子供の関数が命令の実行順序で親関数の前に、命令並び換え部１６による以上の操作によって並び換えられ、親関数は、子供関数の実行結果が代入されたオペランド（インスタンス名が付けられた変数）を用いて実行される。

このような並び換えにより、命令スタックとデータスタックを持たない装置（例えば、手続き型の命令処理を実行する装置）において、関数型制御言語を実行することが可能となる。

但し、上記の命令並び換え部１６の処理は、特許文献４における命令並び換え部１５と略同様の処理機能と見做してもよい。本例の命令並び換え部１６では、更に、条件分岐の関数ノードを検出した場合に、後述する処理を行うことで、ＦＣＬの条件分岐命令を、変換先の手続型言語における適切な条件分岐の構文へと変換することが可能となる。

一般に変換先の手続型言語では適切な条件分岐の構文があり、ＦＣＬの条件分岐命令を適切な構文に変換することができれば、余分な処理実行や一時変数を作成することもなく、効率的な実行が可能である。

上記のように、命令並び換え部１６は、上記ツリー構造を順にたどり、子供ノードがリーフしかないノード（変換対象ノードとする）を見つける毎に、手続型言語プログラムへの変換を行うと共に、必要に応じて変換結果を手続型言語格納部１７に格納する。

この変換は、基本的には、上記特許文献４と略同様に、変換対象ノードに記述された関数呼び出し（記述された関数に対応する変換先の関数等と、子供ノードに記述された引数等を用いて作成）と、その結果の代入文を作成する。代入先は変換対象ノードのインスタンス名とする（インスタンス変数を代入先とする）。

但し、本手法の場合、変換対象ノードに記述された関数が条件分岐である場合、代入文ではなく、対応する手続型言語条件分岐構文に変換する。これについては詳しくは後述する。

上述した各種処理により、ネストされた子供の関数が親関数の前に並び換えられ、子供関数の実行後に、この実行結果を用いて親関数が実行されるので、命令スタックとデータスタックが無くても、問題なく実行できる形式へと変換されることになる（この点は、特許文献４と略同様）。

これに加えて、本手法では、条件分岐関数によって実行制御される部分は、対応する手続型言語条件分岐構文に変換されるのであって、特に、条件分岐の結果に応じて一方の処理だけが実行される形式となるので、無駄な処理が行われることが無くなる。更に、上記のように、条件分岐関数に係る子供ノードに同一のインスタンス名を付与されることで、インスタンス変数の数を削減することもできる。

図６〜図９に、本例の言語変換装置１０の処理フローチャート図を示す。
図６は全体フローチャート図、図７〜図９は図６の各処理の詳細フローチャート図である。

図６において、まず、二次元構造（ツリー）変換部１２が、上記のように既存の処理によって、関数型言語格納部１１に格納されているＦＣＬプログラムを、二次元構造（ツリー構造）に変換する（ステップＳ１）。

このツリー構造の各ノード（但し、リーフは除く）に対して、関数名−インスタンス名作成部１４によって、ツリー内でのユニークなノード識別子（本例ではインスタンス名）を割り当てる。但し、その際、インスタンス名管理部１５によって、複数のノードに同じインスタンス名が割り当てられる場合も有り得る（ステップＳ２）。ステップＳ２の処理の詳細は、図７に示し、後に説明する。

尚、上記作成されたツリー構造は、二次元構造格納部１３に格納される。
そして、上記ツリー構造の先頭ノードに、走査位置（例えば上記“現在処理中ノード”を示すポインタ等）をセットする（ステップＳ３）。そして、この走査位置を末端方向へ向けて順次移動させながら（“現在処理中ノード”を順次変えながら）、子供ノードがリーフだけであるノードを探索する（ステップＳ４）。ステップＳ４の処理の詳細は、図８に示し、後に説明する。

上記ステップＳ４で探し出したノード（変換対象ノード）に関して、手続型言語に変換する処理を行う（ステップＳ５）。ステップＳ５の処理の詳細は、図９に示し、後に説明する。

そして、変換対象ノードの子供ノード（リーフ）を全て削除する（ステップＳ６）。この削除によってツリー構造上のノードが１個だけの状態となったら（ステップＳ７，ＹＥＳ）本処理は終了する。一方、未だ２個以上のノードが残っているならば（ステップＳ７，ＮＯ）、上記走査位置を変換対象ノードの親ノードにセットして（当該親ノードを新たな“現在処理中ノード”にして）（ステップＳ８）ステップＳ４の処理に戻る。

図７は、上記ステップＳ２のインスタンス名割当て処理の詳細フローチャート図である。
図７の処理では、ツリー構造の先頭から各ノードを順次“現在処理中ノード”として、現在の“現在処理中ノード”が、条件分岐の関数（ここでは“（ＩＦ”）に係るノードである場合には（ステップＳ２１，ＹＥＳ）、このノードの子供ノードの数をカウントし（ステップＳ２２）、子供ノードが２個であるか否かを判定する（ステップＳ２３）。

ここで、“現在処理中ノード”の関数が条件分岐ではない場合（ステップＳ２１，ＮＯ）もしくは条件分岐であるが子供ノードが２個である場合には（ステップＳ２１、Ｓ２３がＹＥＳ）、上記特許文献４のような従来通りの方法で各子供ノードにユニークな（異なる）インスタンス名を付与する（勿論、従来手法の通り、子供ノードがリーフの場合にはインスタンス名の付与は行われない）（ステップＳ２５）。

一方、“現在処理中ノード”の関数が条件分岐であり（ステップＳ２１，ＹＥＳ）、且つ、その子供ノードが２個ではない場合には（ステップＳ２３，ＮＯ）、これは基本的には子供ノードが３個であることを想定しており、３個の子供ノードのうち１番目と２番目に関しては上記従来手法によりユニークな（異なる）インスタンス名を割り当てる（勿論、リーフの場合には付与しない）。更に、３番目の子供ノードに対しては、２番目の子供ノードと同一のインスタンス名を割り当てる（ステップＳ２４）。

上述した処理によって、例えば図４に示す例におけるインスタンス名＝“INST_3”のノードが“現在処理中ノード”であるときには、その子供ノードは３個（ノードの名称が“（＞”と“（−”と“（−”の３個）であるのでステップＳ２３の判定はＮＯとなる。そして、これら３個のノードは何れもリーフではないので、Ｓ２４の処理によって、上記１番目のノード（“（＞”のノード）と２番目のノード（１つ目の“（−”のノード）とには、ユニークなインスタンス名が割り当てられると共に（それぞれ、“INST_4”、“INST_5”が付与される）、３番目のノード（２つ目の“（−”のノード）には、２番目のノードと同じインスタンス名（＝“INST_5”）が付与される。

これによって、図４に示すように、３番目のノードのインスタンス名は、図３に示す従来例とは異なるものとなる。また、これに伴って、それ以降のノードへのインスタンス名割当ても、（数値が１つ繰り上がるので）図３とは異なることになる。

図８は、上記ステップＳ４の「子供ノードがリーフだけのノードを探索する」処理の詳細フローチャート図である。
図８の処理では、現在、走査位置があるノード（“現在処理中ノード”）について、この“現在処理中ノード”の最初の子供ノード（“子供ノードへのポインタ”が示すノード）に走査位置をセットした後（つまり、当該最初の子供ノードを、新たな“現在処理中ノード”とする）（ステップＳ４１）、ステップＳ４２以降の処理を繰り返す。

すなわち、まず、現在の上記“現在処理中ノード”（上記の通り、現在は、上記最初の子供ノードが“現在処理中ノード”）が、リーフであるか否かを判定し（ステップＳ４２）、リーフではない場合には（ステップＳ４２，ＮＯ）、この“現在処理中ノード”の最初の子供ノード（“子供ノードへのポインタ”が示すノード）に、走査位置を移動させて（新たな“現在処理中ノード”にして）（ステップＳ４６）、ステップＳ４２に戻る。

この様にして、リーフが見つかるまでツリーの末端方向へ順次、走査位置を移動させていき、リーフが見つかったら（ステップＳ４２，ＹＥＳ）、これが（現在の“現在処理中ノード”が）最後のノード（“次のノードへのポインタ”がＮＵＬＬであるノード）であるか否かを判定し（ステップＳ４３）、最後のノードではない場合には（ステップＳ４３，ＮＯ）、上記現在の“現在処理中ノード”における“次のノードへのポインタ”が示すノードに、走査位置を移動させて（ステップＳ４４、ステップＳ４２に戻る。

そして、途中でステップＳ４２の判定がＮＯとなることなく、走査位置が上記最後のノードにある状態となったら（ステップＳ４３，ＹＥＳ）、現在の“現在処理中ノード”の親ノードは、その子供ノードが全てリーフであることになるので、現在の“現在処理中ノード”の親ノードを探索結果（つまり、上記変換対象ノードである）として返して（ステップＳ４５）、本処理を終了する。

上記ステップＳ５では、上記ステップＳ４５で返された探索結果を用いて、処理実行することになる。
図９は、上記ステップＳ５の「検索されたノード位置を手続型言語に変換する」処理の詳細フローチャート図である。

図９の処理は、上記識別子（インスタンス名）を付与後のツリー構造の各ノードに基づいて、手続型言語への変換を行う処理であって、特に、変換対象ノードが条件分岐の関数に係わるノードである場合には、予め登録されている所定の雛形を用いて手続型言語プログラムの生成を行う処理である。

上記所定の雛形は、例えば、ｉｆ〜ｔｈｅｎ〜ｅｌｓｅ文である。そして、上記条件分岐の関数に係わるノードの各子供ノードに係わる手続型言語への変換結果（一時的に記憶している）を、上記所定の雛形の該当箇所（後述する“条件部”や“ｔｈｅｎ部”など）に当て嵌めることで、上記手続型言語プログラムの生成を行うものである。これについて、詳細な一例を、図９と下記の説明に示す。

図９の処理は、上記ステップＳ４で検索された変換対象ノード（子供ノードがリーフだけのノード）について、当該変換対象ノードの“ノードの名称”が「（ＩＦ」であるか否かを判定する（ステップＳ５１）。つまり、条件分岐の関数ノードであるか否かを判定する。

対象ノードが「（ＩＦ」ではない場合には（ステップＳ５１，ＮＯ）、従来（特許文献４など）と同様の変換処理を行う（ステップＳ５５）。これは、例えば上記図１５（ｂ）に関する説明で述べたように、例えば、基本的には、各変換対象ノード毎に、変換対象ノードに係る関数について、該変換対象ノードの各子供ノードに係る各オペランドまたは識別子を引数として用いて、該変換対象ノードの識別子（インスタンス名）を代入先とする命令文（代入文）を生成するものである。

但し、本例の場合、変換処理は行うが、変換結果を直ちに手続型言語格納部１７に出力するのではなく、一時的に記憶する。そして、ステップＳ５１がＹＥＳになったときに、一時的に記憶されていた変換処理結果を上記所定の雛形に当て嵌めることで、手続型言語の適切な条件分岐処理を生成する（ステップＳ５２）。そして、この生成結果を手続型言語格納部１７に出力すると共に、上記一時的に記憶されていた変換処理結果を全て消去する。但し、ステップＳ５１が一度もＹＥＳとならずに処理終了する場合には、終了する前に、一時的に記憶してあった変換処理結果を全て、手続型言語格納部１７に出力する。

図４の例の場合、最初は図１５（ｂ）に示す先頭から３行目までの３行分（但し、３行目は、INST6→INST5になる）が、上記変換処理結果として一時的に記憶されることになる。尚、上記の通り、図１５（ｂ）に示すfuncGT等は、変換先の言語の関数を便宜上表しているものであり、実際には例えばfuncGT（a,b）は例えば「ａ＞ｂ」、funcSub（a,b）は例えば「ａ−ｂ」等であるものとする。

上記従来の変換処理によれば、そのときの変換対象ノードの子供ノード（リーフ）は全て削除されるので、上記３行分の変換処理後は、図４に示すインスタンス名がINST_3のノードが、変換対象ノードとなり、ステップＳ５１の判定がＹＥＳとなることになる。

この場合、この変換対象ノードの最初の子供ノードに係る上記一時的に記憶されている変換結果（すなわち、最初に記録された変換結果）を“条件部”、２番目の子供ノードに係る上記一時的に記憶されている変換結果（（すなわち、２番目に記録された変換結果）を“ｔｈｅｎ部”として、これらを予め登録されている下記の第1の雛形に当て嵌める（ステップＳ５２の処理）。

『 ｉｆ（条件部）｛
ｔｈｅｎ部；
｝ 』
これによって、上記の例の場合、下記の変換結果が得られて、これが手続型言語格納部１７に出力されて書き込まれることになる。尚、上記一時的に記憶してあった変換結果は、手続型言語格納部１７に出力したら削除する。

『 ｉｆ（ａ＞ｂ）｛
INST_5 ：＝ ａ−ｂ
｝
そして、変換対象ノードに３番目の子供ノードが無い場合には（ステップＳ５３、ＮＯ）、そのまま本処理を終了する（但し、未処理部分があるならばステップＳ５１に戻る）。

一方、変換対象ノードに３番目の子供ノードがある場合には（ステップＳ５３、ＹＥＳ）、３番目の子供ノードに係る上記一時的に記憶されている変換結果を“子供ノードの内容”として、これを予め登録されている下記の第２の雛形に当て嵌める（ステップＳ５４）。

『 ｅｌｓｅ｛
子供ノードの内容
｝ 』
これによって、上記の例の場合、下記の変換結果が得られて、これが手続型言語格納部１７に出力されて書き込まれることになる。

『 ｅｌｓｅ｛
INST_5 ：＝ ｂ−ａ
｝ 』
尚、ステップＳ５２、Ｓ５４の処理において、任意の変換結果を雛形に当て嵌めた直後に、更に、次の変換結果も参照して、当該次の変換結果に、上記雛形に当て嵌めた変換結果における代入先のインスタンス名が含まれている場合には、更に当該次の変換結果も続型言語格納部１７に出力して書き込むようにしてもよい。

これは、例えば、図９のステップＳ５１の処理で２つ目の「（ＩＦ」が検出され、その最初の子供ノードに係わる上記変換結果である「INST_5 ＝ １０」が上記“条件部”として出力されることで、図５に示す例における
ｉｆ（INST_5 ＝ １０）
の部分が生成されるが、その際、更に、２番目の子供ノードに係わる上記変換結果である「INST_7 ：＝ ａ＊ａ」を参照して、これに上記INST_5が含まれているか否かを判定する。この場合は、含まれていないので、何も行わない。

そして、続いて、上記２番目の子供ノードに係わる上記変換結果である「INST_7 ：＝ ａ＊ａ」が、上記“ｔｈｅｎ部”として出力されることで、図５に示す例における
INST_7 ：＝ ａ＊ａ；
の部分が生成されるが、その際、更に、その次の変換結果である「INST_6 ：＝ （ｃ：＝INST_7）」を参照して、これに上記INST_7が含まれているか否かを判定する。この場合は含まれているので、「INST_6 ：＝ （ｃ：＝INST_7）」も更に出力する。

これによって、この場合にはステップＳ５２の処理によって図５に示す例における
ｉｆ（INST_5 ＝ １０）｛
INST_7 ：＝ ａ＊ａ；
INST_6 ：＝ （ｃ：＝INST_7）；
の部分が、生成されることになる。

これは、ステップＳ５４の処理においても同様であり、その結果、図５に示すように、elseに関して、２つの変換結果が出力されることになる。
尚、この場合、上記ステップＳ５３の「変換対象ノードに３番目の子供ノードがある場合には（ステップＳ５３，ＹＥＳ）」は、例えば、それまでにｎ番目の子供ノードに係わる変換結果を出力した場合に、「変換対象ノードにｎ＋１番目の子供ノードがある場合には（ステップＳ５３，ＹＥＳ）」に置き換えるものとする。

図１５（ａ）のプログラムの変換に関しても、図５のように手続型言語の条件分岐を使用した構文に変換できれば、変数は３個（INST5, INST6, INST7）でよく、プログラム実行時に実行される部分も枠で囲んだ５個の実行文（実際には条件分岐の結果次第で別の部分が実行される場合がある）で済み、効率的になる。

尚、勿論、本発明では、特許文献４の発明と略同様に、関数型制御言語で記述されたプログラム内容を並び換え、並び替えにより必要となる一時変数を生成、管理する手段を設けることにより、命令スタックとデータスタックを待たない手続き形の命令処理を行なう装置（代入および処理の呼び出しで構成される装置）で関数型制御言語を実行できるようになるという効果も得られる。

１０ 言語変換装置
１１ 関数型言語（ＦＣＬ）格納部
１２ 二次元構造（ツリー）変換部
１３ 二次元構造格納部
１４ 関数名−インスタンス名作成部
１５ インスタンス名管理部
１６ 命令並び換え部
１７ 手続型言語格納部

Claims (8)

1. 関数型言語で記述された制御処理プログラムを、手続型の命令処理を行う装置で実行可能な言語形式のプログラムである手続型言語プログラムに変換する言語変換装置において、
   前記関数型言語で記述された制御処理プログラムにおける関数又はオペランドの各要素の配列を記憶した関数型言語記憶手段と、
   前記配列の各要素を順次取得し、該各要素に応じたノードと該ノード間のリンクから成るツリー構造を生成するツリー構造作成手段と、
   前記ツリー構造中のノードは、子供ノードを持たないノードであるリーフと、該リーフ以外のノードである子持ノードとから成り、該ツリー構造中の各ノードのうち該子持ノードにユニークな識別子を付与すると共に、条件分岐の関数に係わるノードの子供ノードには、同一の識別子を付与する識別子付与手段と、
   前記識別子を付与後の前記ツリー構造の各ノードに基づいて前記手続型言語への変換を行う手段であって、変換対象ノードが前記条件分岐の関数に係わるノードである場合には、予め登録されている条件分岐処理に係る所定の雛形を用いて前記手続型言語プログラムの生成を行う変換手段と、
   を有することを特徴とする言語変換装置。
2. 前記所定の雛形は、ｉｆ〜ｔｈｅｎ〜ｅｌｓｅ文であり、
   前記変換手段は、前記条件分岐の関数に係わるノードの各子供ノードに係わる前記手続型言語への変換結果を、前記所定の雛形の該当箇所に当て嵌めることで、前記手続型言語プログラムの生成を行うことを特徴とする請求項１記載の言語変換装置。
3. 前記識別子は、前記手続型言語における代入先とし、
   前記識別子付与手段によって前記同一の識別子の付与が行われていることによって、前記ｔｈｅｎに係る前記代入先と、前記ｅｌｓｅに係る前記代入先とに、同一の識別子が用いられることを特徴とする請求項２記載の言語変換装置。
4. 前記識別子付与手段は、前記条件分岐の関数に係わるノードの複数の子供ノードのうちの２番目と３番目のノードに、同一の識別子を付与することを特徴とする請求項１〜３の何れかに記載の言語変換装置。
5. 前記変換手段は、
   そのノードの子供ノードが前記リーフしかないノードを、前記変換対象ノードとし、
   変換対象ノードが前記条件分岐の関数に係わるノード以外のノードである場合には、該変換対象ノードに係る前記関数について、該変換対象ノードの子供ノードに係る前記オペランドまたは前記識別子を引数として用いて、該変換対象ノードの識別子を代入先とする命令文の生成を行って一時的に記憶すると共に、該変換対象ノードの全ての子供ノードを削除することで変換対象ノードを前記リーフとすることを特徴とする請求項２記載の言語変換装置。
6. 前記変換手段は、前記一時的に記憶された各命令文を、前記条件分岐の関数に係わるノードの各子供ノードに係わる前記手続型言語への変換結果として、前記所定の雛形の該当箇所に当て嵌めると共に、前記一時的に記憶された命令文全てを消去することを特徴とする請求項５記載の言語変換装置。
7. 前記ノードは、ノード名称、識別子、子供ノードへのポインタ、親ノードが同一である他のノードをポイントする次ノードへのポインタの各項目を有し、
   前記ツリー構造作成手段は、
   前記配列から取得した要素が任意の関数である場合には、該関数の名称を前記ノード名称とするノードを新規作成すると共に、現在処理中ノードから該新規作成ノードをポイントするポインタを、該現在処理中ノードにおける前記子供ノードへのポインタまたは次ノードへのポインタの何れかに設定し、更に、該新規作成ノードを新たな前記現在処理中ノードとし、
   前記配列から取得した要素が任意のオペランドである場合には、該オペランドの名称を前記ノード名称とするノードを新規作成すると共に、前記現在処理中ノードから該新規作成ノードをポイントするポインタを、該現在処理中ノードにおける前記子供ノードへのポインタまたは次ノードへのポインタの何れかに設定し、更に、該新規作成ノードにおける前記子供ノードへのポインタを無効化し、更に、該新規作成したノードを新たな前記現在処理中ノードとし、
   前記配列から取得した要素が関数終了子である場合には、そのときの現在処理中ノードにおける前記次ノードへのポインタを無効化すると共に、該関数終了子に対応する前記関数に関して作成済みのノードを、新たな前記現在処理中ノードとすることを特徴とする請求項１〜６の何れかに記載の言語変換装置。
8. 関数型言語で記述された制御処理プログラムを、手続型の命令処理を行う装置で実行可能な言語形式のプログラムである手続型言語プログラムに変換する言語変換装置のコンピュータを、
   前記関数型言語で記述された制御処理プログラムにおける関数又はオペランドの各要素の配列を記憶した関数型言語記憶手段と、
   前記配列の各要素を順次取得し、該各要素に応じたノードと該ノード間のリンクから成るツリー構造を生成するツリー構造作成手段と、
   前記ツリー構造中のノードは、子供ノードを持たないノードであるリーフと、該リーフ以外のノードである子持ノードとから成り、該ツリー構造中の各ノードのうち該子持ノードにユニークな識別子を付与すると共に、条件分岐の関数に係わるノードの子供ノードには、同一の識別子を付与する識別子付与手段と、
   前記識別子を付与後の前記ツリー構造の各ノードに基づいて前記手続型言語への変換を行う手段であって、変換対象ノードが前記条件分岐の関数に係わるノードである場合には、予め登録されている所定の雛形を用いて前記手続型言語プログラムの生成を行う変換手段、
   として機能させる為のプログラム。