JPH02183339A - コンピユータ・プログラム変換装置および方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 この発明は全般的にはコンピュータ・プログラム言語の
変換に関し、より具体化にはプログラミング言語トラン
スレータの記述および実行に関連して実行時機能を利用
するようにしたものである。

Ｂ、従来の技術 ］ンピュータ・プログラミング言語を用いて、デジタル
・コンピュータが処理すべき操作シーケンスを記述する
ようになっている。多くの異種のプログラミング言語が
存在し、その幅は、ハードウェアが直接変換するマシン
言語から、ハードウェアによる実行に先立って等価形態
に変換しなければならない高レベル言語まである。

「トランスレーション」　（変換）はプログラムの形態
を１の言語から他の言語に変化きせる事を指す用語であ
る。「コンパイル」は「トランスレーション」の類似語
であるけれども、一般には高レベル言語を機械語すなわ
ちコンピュータ・システムのハードウェアで直接に実行
できる言語に変換する処理を指すものと了解されている
。あるいは高レベル言語を、アッセンブリ言語すなわち
比較的わずかな操作で機械語に直接に変換できる言語に
、変換する処理を指すものと了解されている。

言語トランスレーションをプログラムする際の問題を解
決するために多くの研究がなきれてきた。

そして１つの言語から他の言語へのトランスレータを書
く者をアシストする理論的ないし実際的なツールも利用
可能である。この点に関し、多くの文献があるけれども
、プログラム言語のトランスレーションの理論および実
際を解説するものとして広く知られているものとしては
、”　ＴｈｅＴｈｅｏｒｙ　　ｏｆ　　Ｐａｒｓｉｎｇ
＋　Ｔｒａｎｓｌａｔｉｏｎ　　ａｎｄＣｏｍｐｉｌｉ
ｎｇ”＋　Ａ、ＡｈｏおよびＪ、Ｖｌｌｍａｎ、　Ｐｒ
ｅｍｔｉｃｅ−Ｈａｌｌ、　Ｅｎｇｅｌｗｏｏｄ　　Ｃ
１１ｆｆｓ、　Ｎｅｗ　　Ｊｅｒｓｅｙ　（１９７２）
およびＰｒ１ｎｃｉｐｌｅｓ　ｏｆ　Ｃｏ＋ｎｐｉｌｅ
ｒ　　Ｄｅｓｉｇｎ”。

Ａ、ＡｈｏおよびＪ、Ｖｌｌｍａｎ、　Ａｄｄｉｓｏｎ
−Ｗｅｓｌｅｙ、　Ｒｅａｄｉｎｇ。

−４〜 Ｍａｒｙｌａｎｄ（１９７７）がある。

プログラム言語トランスレータを書くのは大変に複雑で
困難な作業である。トランスレータはいくつかの処理を
実行しなければならず、それら処理の各々は個別的にも
複雑なプログラム上の課題である。これら個別の事項は
広い意味で言えば字句解析、構文解析および意味解析を
含む。これらはソース・　プログラムの解析ならびに最
適化およびコード生成と関連し、また出力ファイルの構
築にも関連する。

トランスレーション処理のある部分は自動化の余地があ
る。とくに、字句解析およびの構文解析のステップは厳
格な形式的な解析にまかきれてきた。その結果、字句ス
キャナすなわち字句解析を実行する部分およびパーサす
なわち構文解析を実行する部分を大体自動的に生成する
ツールを利用できるようになっている。このようなツー
ルの一例はＬｅｘおよびＹａｃｃであり、Ｕｎｉｘ　（
商標）および関連ソフトウェア・システム上で利用可能
である。

ＬｅｘおよびＹａｃｃのような現行ツールではプログラ
ム言語トランスレータを自動的に生成するという観点か
ら望まれる多くの事項を未解決としている。これらツー
ルは字句スキャニングおよび構文パージングを実行する
プログラム・コードを生成するけれども、統合化されて
いない。Ｌｅｘによって生成された統語スキャナの出力
を取り出し、Ｙａｃｃによって生成された構文パーサで
利用可能な入力に変換するコードを書（のは依然人間の
トランスレータ・ライタである。さらに人間のトランス
レータ・ライタはすべての必要な意味解析を作成しなけ
ればならない。

ＬｅｘおよびＹａｃｃような利用可能なプログラムの出
力は、変換すべき言語の仕様に変更があると自動生成コ
ード全体にわたって多くの点で変更が必要となるという
欠点があった。トランスレータ・ライタは、２度目にツ
ールを用いて新しい言語仕様を実行した後に、トランス
レータ・ライタ自身が個別に書いたコードのすべての部
分を変更してＬｅｘおよびＹａｃｃで生成したコードの
変更に適合するようにしなければならない。、このよう
な変更は複雑であり極めて多岐にわたるため、変更によ
り加わったエラーがないと保障するのは困難である。

また一つの部分たとえば字句スキャナになされた変更が
他の部分たとえばパーサに適切に反映すると保障するの
も困難である。

字句スキャナおよびパーサを記述するのに自動化ツール
を使用するかどうかにかかわらず、各プログラム言語ト
ランスレータは字句および構文解析を実行するのに必要
なコードのすべてを含んでいる必要がある。変換される
言語の知識はこのコード中に組み込まれているので、一
般に異なる言語を変換する際に用いるように容易に適合
化するのは不可能である。このことは、わずかであれ重
要な相違があれば、プログラム言語が極めて類似であっ
ても同様である。現在、どのような言語が変換きれるに
しろ、字句スキャニングおよびパージングの処理が極め
て標準的態様で実行されているという利点を十分に利用
したメカニズムは存在していない。

はとんどのプログラム言語において字句スキャニングお
よびパージングは機能的に類似の処理であるという利点
を生かしたシステムを提供することが望まれる。またい
くつかの異なるプログラム言語の各トランスレータとと
もに簡易に用いることができるシステムが望まれる。

Ｃ１発明が解決しようとする課題 この発明は事情を考慮してなきれるものであり、入力言
語の字句スキャニングおよびパージングを行う手順を提
供することを目的としている。

またこの発明はトランスレータを記述する目的言語と無
関係な字句スキャニングおよびパージングの手順を提供
することを目的としている。

またこの発明はトランスレータを記述する目的言語と無
関係な、また入力言語と無関係な字句スキャニングおよ
びパージングの手順を提供することを目的としている。

Ｄ．課題を解決するための手段 この発明では、以上の目的を達成するために、−組の字
句スキャニング及びパージングの手続きが呼び出し可能
なライブラリ・ルーチンとして提供される。入力言語ト
ランスレータは目的言語で記述され、標準の、予め定め
られたデータ構造が目的言語で与えられる。このような
データ構造に含まれる情報は入力言語用の字句解析およ
び構文解析の規則を定義する。ライブラリ・ルーチンは
上述の予め定められたデータ構造を参照し、入力言語プ
ログラムまたはプログラムの断片の完全な字句および構
文解析がライブラリ手続き内で実行される。ライブラリ
手続きの機能は目的言語と独立であり、また入力言語と
も独立である。ただし、入力言語が、ライブラリ手続き
の参照するデータ構造により定義されるという限度で例
外となる。

Ｅ．実施例 以下の説明では３つのプログラム言語に触れる。

これら３つの言語はメタ言語、目的言語および入力言語
である。メタ言語は入力言語を様式化したものである。

入力言語はトランスレータがそのために記述されるとこ
ろの言語である。目的言語はトランスレータを記述する
のに用いる言語である。

第１図において、メタ言語ソース・ファイル１０は入力
言語の形式的な仕様を含んでいる。仕様は好ましくは標
準的なフォーマットたとえばＢａｃｋｕｓ−Ｎａｕｒフ
ォーマット（ＢＮＦ）ときれ、入力言語の語霊、統語仕
様および構文を記述する。

メタ言語ソース・ファイル１０のステートメントはメタ
言語トランスレータ１２より読み取られ、目的言語オブ
ジェクトを含むファイル１４に変換される。

メタ言語トランスレータ１２は、メタ言語ソース・　フ
ァイル１０を以下の特徴を有する目的言語オブジェクト
１４に変換できる任意のプログラムであってよい。この
発明にあっては、メタ言語ソース・ファイル１０および
トランスレータ１２自体はなくてもよく、目的言語オブ
ジェクト１４が直接に保持されてもよい。ただしメタ言
語ソース・ファイル１０を用いれば、一般にユーザ（プ
ログラム言語トランスレータを記述する人）が入力言語
の仕様をより明瞭に理解できることになる。

オブジェクト１４を記述する目的言語は、トランスレー
タを記述するのに適したいがなる言語であってもよい。

そのような言語の例はＣ，Ｐａ５ｃａｌおよびＡｄａで
ある。目標言語の選択は入力言語と別個に行うことがで
き、一般にユーザが使いなれている言語が選ばれる。

目的言語オブジェクト１４は完全なトランスレータを表
わしていない。ユーザは、トランスレータの意味解析部
およびコード生成部を含む１以上のユーザ・ソース・フ
ァイル１６を提供する必要がある。ユーザ・ソース１６
および目的言語オブジェクト１４は目的言語トランスレ
ータ１８への入力として用いられる。目標言語トランス
レータ１８は実行可能な入力言語トランスレータ２ｏを
生成する。このトランスレータ２０は入力言語ソース・
ファイル２２からソース・プログラムを読み出して、変
換済み入力言語ファイル２４を生成する。変換済み入力
言語ファイル２４は実行可能ファイルでもよく、また実
行可能ファイルに実質的に変換で任意の形態のファイル
でもよい。変換済み入力言語ファイル２４の形態は、入
力言語トランスレータ２０のコード生成部によって決ま
り、これはユーザ・ソース・ファイル１６中のコードに
より定義される。

実行時ライブラリ２６は入力言語ソース・ファイル２２
の字句解析および構文解析実行する一組の手続きを提供
する。入力言語トランスレータはライブラリ２６内で、
パーサ・ルーチンを呼び出し、ソース・ファイル２２か
らの入力ストリングおよびパージングすべきゴールをパ
ラメータとして渡す。このゴールはたとえば単一のステ
ートメント、サブルーチンまたは完全なプログラムであ
ってよい。つぎにパーサ・ルーチンは入力ストリングの
構文をチエツクして、要求されているゴールとして有効
かどうかを判別する。たとえば入力言語のプログラム全
体を変換することが望まれるのであれば、プログラム全
体をパージングするためにパーサにゴールが付与される
。入力言語ソース・ファイルが有効な入力言語のプログ
ラムであれば、実行時ライブラリ２６内のパーサが有効
を示す結果を返すことになる。

第２図において、実行時ライブラリ２６内のルーチンの
内部動作が示されている。第１図のステップでは、入力
言語トランスレータ２０が入力ストリングのパージング
に適用されるゴールを決定する。つぎにパーサ３２が呼
び出され、所望のゴールおよび入力ストリングの位置が
パラメータとして渡される。つぎにパーサ３２はスクリ
ーナ３４からのトークンを要求する。これに応じてスク
リーナ３４はスキャナ３６からのトークンを要求する。

スキャナ３６は入力ストリングをスキャニングして字句
オブジェクトの各々を特定する。この特定は、−組の低
レベルＩ１０機能３８から個々のキャラクタを要求して
行なわれる。これは−般にオペレーティング・システム
の一部として供給される。

Ｉ１０機能３８はつぎに単一の継続キャラクタを入力ス
トリングからスキャナ３６に返す。スキャナ３６は所定
の字句オブジェクト用に許容されている一組のキャラク
タを基準に入力キャラクタをチエツクし、受け取ったキ
ャラクタを、単一の字句オブジェクトを表わすトークン
中に結合する。

そのトークンに対するテキスト・ストリングは保持され
、後に使用の際に当該Ｉ・−クンとともに引き渡きれる
。結合処理の間に、スキャナ３６はいくつかの入力キャ
ラクタの変換たとえばタブ・キャリッジ・リターンおよ
びブランク付行送りの置換、複数の継続するブランクの
削除、すべてのアルファベット・キャラクタの大文字化
等を行うことができる。このような文字置換処理は予め
定められた字句オブジェクト・データ構造で定義きれる
方がよい。つぎにスキャナ３６はトークンおよびそのテ
キスト・ストリングをスクリーナ３４に渡す。スクリー
ナ３４は予め定められた予約語の＝１３− 辞書中でトークを検索する。つぎにスクリーナ３４は対
応するトークンをパーサ３２に渡し、パーサ３２はその
トークンをパージング動作に用いる。

パージングが不完全であれば、パーサ３２はスクリーナ
３４からつぎのトークンを要求し、処理が繰り返される
。

パースが終了すると、パーサはその結果を入力言語トラ
ンスレータ２０に戻す。パース終了時、入力言語トラン
スレータは変換済み入力言語ファイル２４のコード生成
の実行に必要なすべての情報を保有している３、 つぎに第３図を参照してスキャナ３６の動作を説明する
。スキャナ３６はまず入力テキスト・ストリングをトー
クン化する。これはテキスト・ストリングを字句規則の
リストと比較することによって行なわれる。字句規則の
各々は（１）すべての有効な初期キャラクタの組、（２
）テキスト・ストリングの本体用に有効なすべてのキャ
ラクタの組および（３）すべての有効な終端文字の組を
定義する。この情報は単一のデータ構造に簡易にストア
することかできる。第３図の４１〜４６のボックスは各
々１つの字句規則を表わす。これらの規則は字句文脈を
定義し、リストを構成するように結合される。この場合
規則４１〜４３は１つの組の最初の３つの規則であり、
規則４４〜４６は２番目の組の最初の３つの規則である
。−組の規則のみが一時に能動ζきれる。

スキャナ３６がテキスト・ストリングのスキャニングを
開始するとき、スキャナ３６はストリングの最初のキャ
ラクタを第１の規則４１として有効な初期キャラクタの
組と比較する。そのキャラクタがその組の中になければ
、次の規則４２として有効な初期キャラクタの組に上述
最初のキャラクタを比較させる。この処理は、一致が判
別されるか、規則のリストの終りに到る（このことは入
力ストリングにエラーがあることを示す）まで続けられ
る。

テキスト・ストリングの最初のキャラクタと所定の字句
規則の初期の最初のキャラクタの組との間に一致がある
と、その規則が選択されてテキスト・ストリングの残り
がスキャンされて、残りのストリングの全キャラクタが
、選択された規則により定義きれる字句オブジェクトの
本体として有効なキャラクタかどうかの判別が行なわれ
る。全テキスト・ストリングが読み出され、字句規則に
正しく一致すると、全テキスト・ストリングはトークン
に変換きれる。この処理にはトークンに字句規則番号を
割り当てる処理も含まれる。

スキャナ３４はまたテキスト・ストリングが予約語かど
うかの判別も行う。この判別は辞書引きと関連して行わ
れる。テキスト・ストリングに対する一致が、辞書中の
予約語の個別のリスト中に見出されると、字句オブジェ
クトに対するトークンＩＤ番号が字句規則ＩＤ番号から
辞書トークンＩＤ番号に切り換えられる。

第３図は字句規則の並行結合リストを示す。各リストは
異なる辞句文脈を表わす。このリストは、単一のソース
・ファイル内の２以上の異なる言語の入力ストリングを
スキャンする必要があるシステムにおいて有益である。

ボックス４８は規則４８で始まる結合リストへのポイン
タである。ただし、破線で示すように、規則４４で始ま
る結合リストをポインタするように変更できる。ポイン
タ４８の値を変更すると、入力テキスト・ストリングに
種々の組の字句規則を適用することができる。

ポインタ４８の値はパーサ３２を呼び出す前に、入力言
語トランスレータ２０によって決定される。

つぎに第４図および第５図を参照してパーサ３２の動作
について説明する。第４図はグラフを構成するように一
体に結合された一連のオブジェクト５１〜５９を示して
いる。オブジェクトの各々は次のオブジェクトへのポイ
ンタ（ＮＥＸＴ）と代替オブジェクトへのポインタ（Ａ
ＬＴ）とを含んでいる。オブジェクトの各々はまたオブ
ジェクトのタイプおよびその値を示す情報を含んでいる
。

好ましい例では、４つのノード・タイプがある。

まず意味機能である。この場合値は、ユーザが供給した
り、マシーンが生成したりする実行すべき意味機能を表
わす。つぎは予約語である。この場合値は予約語のリス
トへのインデックスである。

つぎは字句オブジェクト・タイプである。この場合値は
字句トークンのＩＤ番号（字句規則ＩＤ番号）である。

最後は非終端である。この場合値はポインタ・アレイへ
のインデックスである。ボンダの各々は構文グラフへの
ノードをポイントする。

パーサ３２はトークンを一時に１つずつ読み出して、構
文グラフへのノードに比較して動作を行う。トークンが
グラフの現行ノードが予定するものと一致すれば、パー
サは次トークンを要求し、グラフ３７の次ノードに移動
する。パーサ３２ばＮＥＸＴポインタが空になるまで、
１対１でトークンをノードに突き合わせて構文グラフを
トラバースし続ける。ＮＥＸＴポイントが空であること
は第４図のＮＩＬＬによって示される。ＮＥＸＴポイン
タがＮＩＬＬのとき、第５図を参照して説明されるよう
にゴールまたはサブゴールに到着する。

第５図はパーサ３２の動作を説明する。パーサ３２は入
力言語トランスレータ２０からゴールを受け取る（ステ
ップ７０）。ゴールは入力言語内の識別可能なコード・
ブロックである。たとえば、単一のステートメント、宣
言セクション、サブルーチンまたは全体のプログラムで
ある。入力言語用に定義されている実現可能なゴールは
構文グラフの入口ポイントに対応する。入口ポイントを
構文グラフ内のノードへのポインタからなるアレイに構
成してもよい。こ、のアレイ中の各エントリ（入口）は
それぞれゴールに対応する。後述するように、所定のゴ
ールをパースするには、付加的なサブゴールを生成して
満たすようにしなくてはならないことがある。たとえば
プログラム全体は宣言、サブルーチンおよびステートメ
ントを含むであろうし、サブルーチンはさらに宣言、サ
ブルーチンおよびステートメントを含むことがある。後
述のように、構文グラフはパーサ−によって再帰的にト
ラバースされる。

ゴールに到達すると、パーサは構文グラフの対応するノ
ードを第１ノードとして選択しくステップ７２）、最初
のトークンを取り出す（ステップ７４）。このトークン
およびパーサにより取り出される他のトークンは第２図
を参照して説明したように要求きれ、受け取られる。

パーサが採用する動作は現行ノードのタイプによって決
まり、パーサの制御の流れの分岐はこのノードのタイプ
によって決まる（ステップ７６）。

ノードが終端であれば、値フィールドは満足させられる
べき新しいサブコールを表わす。したがって現行ノード
の識別子がスタックに挿入きれる（ステップ７７）、パ
ーサは表示されたノードにジャンプしくステップ７８）
、これがサブコールに対応する。この処理ではトークン
は使用されない。トークンはＥ移動およびブツシュ・ダ
ウンのオートメーションに対応する。ノード・タイプが
字句オブジェクト・タイプまたは予約語であれば、値フ
ィールドはパースのその時点において予定される字句オ
ブジェクトのＩＤ番号を示す。現行トークンのＩＤ番号
が現行ノードの値に比較される（ステップ７９）。トー
クンＩＤ番号および予定された字句オブジェクト番号が
一致しなければ、ＡＬＴポインタの値がチエツクされる
（ステップ２ｌ− ８０）。このポインタがＮＩＬであれば、入力言語によ
り定義された有効な代替的なパースがなく、エラー状態
が通知される（ステップ８２）。このエラー状態ではパ
ースが中止きれるであろうし、またエラーの位置が示さ
れるであろう。またより複雑なエラー回復ルーチンを採
用してもよい。そうでなければ、ＡＬＴポインタを辿っ
て適切なノドに到り（ステップ８４）、制御をステップ
７６に戻す。この処理でもトークンを使用することはな
い。

ステップ７９においてトークンＩＤ番号が当該ノードに
予定されるＩＤ番号と一致し、イエスの分岐がとられる
と、入力ストリングにまだトークンが残っているかどう
か判別される（ステップ８６）。トークンが利用可能で
あり、すなわちパースが終了していないのであれば、次
トークンを取り出す（ステップ８８）。ＮＥＸＴポイン
タの値がチエツクされＮＩＬかどうかが判別される（ス
テップ９０）。ＮＩＬでなければパーサは次ノードに移
行しくステップ９２）、制御がステップ７６に戻る。こ
の時点で、ステップ８８で得られたトークンがステップ
９２で到されたノードに比較されることになる。

ステップ９０でＮＥＸＴポインタがＮＩＬであると、ス
タックが空かどうかの判別を行う。空であれば、パーサ
はステップで受け取った元のゴールをパースしおえたこ
とになり、パースが終了する。（ステップ９４）。スタ
ックが空でなければ、パーサがサブゴールをパースしお
えたことになり、そのサブゴールを呼び出した時点に制
御を戻ざなければならない。そのために、スタックから
トップ・ノードを取り出しくステップ９５）、当該ノー
ドに移行する（ステップ９２）。

パースがステップ９４で終了すると、入カドークン・ス
トリングはまだ空ではない。これは、パーサがステップ
７０で受け取った元のゴールを完全にパースしたけれど
、入力がまだ残っていることを示す。パーサに供給され
た入力ストリングが、ステップ７０で受け取ったゴール
に正確にパースされるとすると、このような事態はエラ
ーがあつたことを示すことになる。他のシステム・デザ
インではこの状態がエラーを示すのでなく、そのかわり
に元のゴールのパースを終了するのにどのくらい多くの
入力ストリングが読み込まれたかを示す入力ストリング
へのポインタをパーサが返すようにしてもよい。この情
報を用いて入力言語トランスレータ２０がつぎに取るべ
き動作を決定することができる。

ステップ８６のテストにおいて、入カドークンがないこ
とが示されると、入力ストリングが使用しつくされたこ
とになる。この時点では、パースを終了するためにこれ
以上の入カドークンを読みだす必要はないであろう。た
だしパーサは一連のサブコールに到る複数のレベルの深
ざを有しており、一連のＥ移動においてパース・スタッ
クが空になり得るかどうかを決定する必要がある。

ステップ９６において、現行ノードのＮＥＸＴポインタ
をチエツクしてＮＩＬがどうかを調べる。

ＮＩＬでなければエラー状態が起こる（ステップ９８）
。これは、入力ストリングは消費しつくされたけれども
、パーサはそのパースの終了のために他の入力をざらに
必要とすることを意味する。

エラー処理はステップ９８において行われる。

ステップ９６のテストがＮＥＸＴポインタがＮＩＬであ
ることを示すと、パース・スタックをチエツクしてスタ
ックが空かどうかを調べる（ステップ１００）。空であ
れば、入力ストリングが使用しつくされたのと同時にス
タックが空にされたのであり、正しいパースが完了され
たことになる（ステップ１０２）。この状態は入力言語
トランスレータに通知きれる。

ステップ１００においてステップがまた空でないことが
示されると、トップ・ノードがスタックから取り出され
（ステップ１０４）、そのＮＥＸＴポインタをチエツク
してＮＩＬかどうかを調べる（ステップ９６）。ステッ
プ９６．１００および１０４のループはスタックが空に
なるか、ＮＥＸＴポインタとしてＮＩＬを持たないノー
ドが取り出されるまで続けられる。

ステップ７６で検出されたノード・タイプが意−２５＝ 味機能であれば、その機能を呼び出す（ステップ１１０
）。意味機能はユーザーにより供給されたり、パーサに
対する補助的な機能としてメタ言語トランスレータによ
って生成され、パーサ３２に渡される入力言語ストリン
グの意味解析を実行する。これには、シンボル・テーブ
ル操作、タイプを変数に関連付ける操作等の機能が含ま
れる。コード生成はステップ１１０によって呼び出され
る機能によって実行される。パースの間に意味機能を実
行できるから、パース終了後に意味解析を実行するパー
ス・トリーをパーサが生成する必要がない。ユーザはユ
ーザが記述した意味機能において必要であればパース・
トリーを構築でき、コードを直接に生成してもよい。

意味機能はパースを継続してもよいかどうがを示す終了
コードを返すことができる。たとえば、入力言語の構文
は特定の時点で変数を要求してもよい。しかし入力スト
リングは、現行トークンが不適切にタイプの混在した表
現を生成するのであれば、無効ときれるべきである。同
様な状況での変数タイプを意味機能によってテストされ
、この意味機能はトークンが実際に有効かどうかを示す
値を返すことができる。この返却された値をステップ１
１２においてチエツクし、もし終了コードが成′功であ
れば制郡をステップ８６に戻す。他方終了コードが成功
でなければエラーを返す（ステップ１１４）。

Ｆ１発明の効果 第４図の構文グラフのノード中に含まれるデータが入力
言語の構文を定義する場合には、第５図のパーサが再帰
的にそのグラフをトラバースして入力ストソングをパー
スすることは明らかである。パーサ自体は入力言語に特
有の情報を何ら有さす、そのかわりパースの標準的なス
テップを抽出する。具体的な入力言語に特有の情報は、
予め定められ、かつパーサが利用できる標準的なデータ
構造内にすべて含まれている。

なお、第５図のパーサはＬＬ　（０）パーサを実現して
いることは当業者に明らかであろう。

【図面の簡単な説明】

第１図はこの発明の一実施例のシステムを示すブロック
図、第２図は上述実施例の字句スキャンおよびパース・
ルーチンを説明するフローチャート、第３図は上述実施
例の字句スキャナが用いるデータ構造を示す図、第４図
は上述実施例のパーサが用いる構文グラフを示す図、第
５図は上述パーサの動作を説明するフローチャートであ
る。 １０・・・・メタ言語ソース・ファイル、１２・・・・
メタ言語トランスレータ、１４・・・・目的言語オブジ
ェクト、１６・・・・ユーザ・ソース・ファイル、１８
・・・・目的言語トランスレータ、２０・・・・入力言
語トランスレータ、２２・・・・入力言語ソース・ファ
イル、２４・・・・変換済み入力言語ファイル、２６・
・・・実行時ライブラリ。

Claims (2)

【特許請求の範囲】
1. （１）コンピュータ・プログラムを含む入力言語ソース
   ファイルと、 上記入力言語ソース・ファイルと結合されたトランスレ
   ータであつて、予め定めらせれたフォーマットを有し上
   記入力言語の字句の特徴および構文の特徴を定義する複
   数のデータ構造を含み、上記入力言語ソース・ファイル
   を読み込んで上記コンピュータ・プログラムを変換する
   ものと、上記トランスレータに結合されて、変換された
   上記コンピータ・プログラムを受け取る変換済みファイ
   ルと、 上記トランスレータから呼び出されるルーチンを有する
   手続きライブラリであつて、上記予め定められたフォー
   マットの上記トランスレータのデータ構造を上記ルーチ
   ンが利用して上記入力言語ソース・ファイルの字句解析
   および構文解析を実行するものとを有し、 上記ルーチンが入力言語及び目的言語と無関係となるよ
   うにしたことを特徴とするコンピュータ・プログラム変
   換装置。
2. （２）入力言語でコンピュータ・プログラムを定義する
   キャラクタのシーケンスを含むソース・ファイルを供給
   するステップと、 予め定められたフォーマットを有し上記入力言語の字句
   の特性をおよび構文の特性を定義する複数のデータ構造
   を供給するステップと、 供給された入力の字句解析および構文解析を実行するた
   めに上記データ構造を利用し、その解析結果を返すルー
   チンのライブラリを供給するステップと、 入力として供給される上記ソース・ファイルとともに上
   記ルーチンのライブラリを呼び出すステップと、 上記ルーチンのライブラリによる結果に基づいて上記ソ
   ース・ファイルの変換結果を出力ファイルに書き込むス
   テップとを有することを特徴とするコンピュータ・プロ
   グラム変換方法。