JPH02183338A - プログラム言語トランスレータ生成装置および方法 - Google Patents

Abstract

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

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 この発明は全般的にはコンピュータ・プログラミング言
語の変換に関し、より具体的にはコンピュータ・プログ
ラミング言語用のトランスレータを記述するプロセスを
自動化するシステムおよび方法に関する。

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

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

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

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

ＡｈｏおよびＪ、Ｖｌｌｍａｎ、Ｐｒｅｎｔｉｃｅ−１
１ａｌｌ、ＥｎｇｅｌｗｏｏｄＣｌｉｆｆｓ、Ｎｅｗ　
Ｊｅｒｓｅｙ（１９７２）および“Ｐｒ１ｎｃｉｐｌｅ
ｓｏｆ　Ｃｏｍｐｉｌｅｒ　Ｄｅｓｉｇｎ”　、Ａ、Ａ
ｈｏおよびＪ、Ｖｌｌｍａｎ。

Ａｄｄｊｓｏｎ　Ｗｅｓｌｅｙ、Ｒｅａｄｉｎｇ、Ｍａ
ｒｙｌａｎｄ（１９７７）がある。

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

トランスレーション処理のある部分は自動化の余地があ
る。とくに字句解析および構文解析のステップは厳格な
形式的な解析にまかされてきた。

その結果、字句スキャナすなわち字句解析を実行する部
分およびパーサすなわち構文解析を実行する部分を大体
自動的に生成するツールを利用できるようになっている
。このようなツールの一例はＬｅｘおよびｙａｃｃであ
り、Ｕｎｉｘ　（商標）および関連ソフトウェア・シス
テム上で利用可能である。

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

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

プログラム言語トランスレータ生成処理の部分を、種々
の部分の間の一貫性を、穏やかな要件の下で保障しなが
ら自動化するシステムを提供することが好ましい。さら
にトランスレータのうち自動的に生成された部分と、人
間のトランスレータ・ライタが書くべき部分との間のイ
ンターフェースを簡易に行えるシステムが望まれる。

Ｃ１発明が解決しようとする課題 この発明は以上の事情を考慮してなされたものであり、
プログラムの言語トランスレータのソース・コードの部
分を自動的に生成するシステムおよび方法を提供するこ
とを目的としている。

またこの発明はトランスレータのうちユーザが記述すべ
き部分と簡易にインターフェースを行いながらトランス
レータのソース・コードの部分を自動的に生成するシス
テムおよび方法を提供することを目的としている。

さらにこの発明は変換すべき言語に仕様変更がある場合
に簡易にメインテナンスを行えるシステムを提供するこ
とを目的としている。

９１課題を解決するための手段 この発明では以上の目的を達成するために、入力言語の
仕様を目的言語の一組のオブジェクトに変換し、これら
オブジェクトを目的言語のプログラム・コードと結合し
て入力言語用のトランスレータを生成するようにしてい
る。

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

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

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

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

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

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

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

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

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

変換済み入力言語ファイル２４の形態は、入力言語トラ
ンスレータ２０のコード生成部によって決まり、これは
ユーザ・ソース・ファイル１６中のコードにより定義さ
れる。

第２図は変換済み入力言語ファイル２４を生成するため
に第１図のシステムで実行する一連のステップを示して
いる。まず入力言語の形式定義を生成する（ステップ３
０）。そしてこれをメタ言語ソース・ファイル１０に配
置する。つぎに形式定義を目的言語オブジェクト１４に
変換する（ステップ３２）。ユーザ・ソース・コード１
６（自動生成された目的言語オブジェクトと別個に生成
されている）を結合する（ステップ３４）。そして入力
言語トランスレータを生成する（ステップ３６）。つぎ
に入力言語トランスレータ２０を用いて入力言語ソース
を変換する（ステップ３８）。

目的言語オブジェクト１４はその性質および機能から、
入力言語トランスレータの字句解析、構文解析および意
味解析の部分を高レベルに統合できる。表１は好ましい
実現例で用いる１１個の標準オブジェクトのリストであ
る。

犬よ １）辞書 ２）アルファベット定義 ３）字句オブジェクト ４）字句規則リスト ５）字句スキャナ・オブジェクト ６）文法ゴール ７）トータル・グループ・メンバーシップ８）意味機能
リスト ９）構文グラフ・ノード １０）構文グラフ １１）パーサ・オブジェクト 第１のオブジェクトは辞書である。辞書は入力言語用に
語常または予約語を含んでいる。辞書のデータ構造タイ
プは実現急用に応じて決定され、好ましくは効率を向上
させる点からオープン・アドレスのハツシング・スキー
ムを採用する。

２番目のオブジェクトはアルファベット定義オブジェク
トである。このオブジェクトは、入力言語ソース・ファ
イル２２をなすキャラクタ・ストリームを、トランスレ
ータ２０で用いる内部アルファベットに再定義するのに
用いる。アルファベット定義オブジェクトを用いてユー
ザ定義クラスを保持する。ユーザ定義クラスは字句オブ
ジェクトの定義において単一のエンティティとして扱う
ことができる。アルファベット定義オブジェクトを用い
て通常すべてのキャラクタを大文字ないし小文字に変換
し、またすべての空白（余白）キャラクタたとえばブラ
ンク、タブ、ライン・フィード、キャラリッジ・リター
ンを単一の空白キャラクタ、通常はＡＳＣＩＩの“ｂｌ
ａｎｋ”キャラクタに変換する。アルファベット定義オ
ブジェクトは効率良く、−次元アレイのキャラクタとし
て実現できる。入力ファイル２２から読み出された各キ
ャラクタのＡＳＣＩＩ値はアレイのインデックスとして
用いられ、アレイの各位置のキャラクタがキャラクタの
変換値となる 字句オブジェクトは入力言語のトークンに用いる字句規
則を定義する。３）字句オブジェクトおよび４）字句規
則リストについては第３図を参照して詳細に説明する。

表１の第５番目のオブジェトクは字句スキャナ・オブジ
ェトクであり、字句スキャナが必要とするすべてのデー
タ構造を識別する。表１に示した好ましい実現例では、
これはシンプルストラフチャ（Ｃ）またはレコード（Ｐ
ａｓｃａｌ）であり、項目１〜４へのリンク（たとえば
ポインタ）を含んでいる。

項目６−１１は入力言語ソース・ファイル２２の構文解
析に用いる。一般に、パーサは許容される構文構造を表
現するグラフをトラバース（横断）して動作する。文法
ゴール・オブジェクト（表１の第６番目）は構文グラフ
内の所定のノードへのポインタを含む。これらポインタ
は、選択された構文構造たとえばプログラム、サブルー
チン、およびステートメント等を定義するために用いる
第１のノードをポイントする。このオブジェクト自体は
ポインタのアレイとして実現できる。

表１の第７番目のオブジェトクすなわちトータル・グル
ープ・メンバーシップは、トークンが予め定められたト
ータル・グループの中の１のトークンかどうかを判別す
るのに用いられる。このオブジェクトは種々の態様で実
現することができる。

好ましくは所定のトークンが具体的なグループに含まれ
るかどうかを表わすプール値を返す１グループの機態か
らなる。あるいは、組のメンバーシップを判別する他の
手法を用いてもよい。

第８番目のオブジェクトすなわち意味機能リストは、ユ
ーザの個別に記述されたソース・ファイル１６中にユー
ザにより供給される意味機能へのポインタのリストであ
る。これら手続き（機能）へのポインタはアレイに効率
良くストアできる。

アレイへのインデックスはどの意味機能が用いられるべ
きかを表わすのに用いられる。第４図および表３を参照
して後述するように、パーサはこのアレイで参照される
任意のユーザ供給機能を呼び出すことができる。

第９番目のオブジェクトすなわち構文グラフ・ノードは
構文グラフすなわち第１０番目のオブジェクトのすべて
のノードのテンプレートである。

パーサは第４図参照して後述するようにこのグラフをト
ラバースして動作する。

最後のオブジェクトは、パーサ・オブジェクトであり、
このオブジェクトは単にベース位置であり、必要なデー
タ構造の残りを特定する。したがってパーサ・オブジェ
クトは要素５．６．７．８および１０の各々へのリンク
を含む。

表１に挙げたオブジェクトはすでに初期化されているデ
ータ構造として供給される。たとえば構文グラフは、メ
タ言語ソース・ファイル１ｏに与えられているＢＮＦ風
のプロダクション（生成）に基づいて完全に構築される
。表１に挙げられているオブジェクトは標準フオームで
あり、入力言語の具体的な要件にしたがって変更する必
要がないことが好ましい。なすなわち単一の目的言語を
用いて種々の異なる入力言語トランスレータを記述する
のなら、標準オブジェクト１４のフォーマットを同じも
のにできる。単にオブジェクトに配す実際の値たとえば
辞書、トークン・グループ・メンバーシップおよび構文
グラフを変更するだけでよい。

表１に示したオブジェクトのうちのいくつかをより詳細
に説明しよう。表２は字句オブジェクト中に含まれる情
報を示す。初期キャラクタの組みは、単に字句トークン
を表わすキャラクタ・ストリングの最初のキャラクタと
して許容されるキャラクタの組みである。本体中のキャ
ラクタの組みは同様に許容されるキャラクタの組みであ
る。ただし字句トークン中の最後のキャラクタとして許
容される。キャラクタの部分集合である。スキャナが空
白キャラクタ等の区切りを次キャラクタとして読み出そ
うとするとき、現キャラクタは終了キャラクタの組みの
要素でなければならない。そうでなければ現行の字句オ
ブジェクトは有効でない。終了キャラクタの組みが空集
合であれば、空白キャラクタは字句トークンの終了とし
て解釈される。

スーー々 １）初期キャラクタの組み ２）本体のキャラクタの組み ３）終了キャラクタの組み ４）次字句要素へのポインタ ５）許容キャラクタの最大数 ６）キャラクタ出力ファイル・フラグ ７）キャラクタ・バッファ・フラグ ８）終端包含規則 各字句要素は１つの種類の字句オブジェクトをスキャン
する規則を定義する。各タイプの多くの異なる字句オブ
ジェクトが、通常、単一のプログラムの処理の間にスキ
ャンされる。字句要素のタイプはたとえば識別子、数、
操作子、ストリングおよびコメントを含む。

次の字句要素へのポインタすなわち表２の第４番目の項
目は字句要素のリストを一緒に結合するのに用いられる
。第３図は生成された字句規則リスト構造を示す。字句
規則リスト（表１の項目４）自体は第１の字句要素５２
への単なるポインタ５０である。字句要素５２はっぎの
字句要素５４をポイントする。この結合リスト構造によ
り、字句スキャニング時に簡易に文脈切り換えを行える
。

２つの異なる入力言語を含む入力ファイルを変換できる
ようにするのが望まれるのであれば、個別の結合リスト
を双方の字句規則用にそれぞれ保持できる。文脈切り換
えを行うには単に字句規則リスト・ポインタ５０を切り
換えて規則の第２リスト中の第１の字句要素をポイント
するようにするだけでよい。

表２の項目５は、トークン中に最大許容文字数がある場
合に、その値を示す。第６項目は、入力文字が読み出さ
れるときにそれら入力文字が出力ファイルにコピーされ
るかどうかを示すのに用いるプール・フラグである。文
字を出力ファイルにコピーすることにより、コンパイル
の出力リストを生成する。第７項目は、トータルが生成
されたのちにこのトータルをバッファに一時的にストア
するかどうかを示すプール・フラグである。パーサが使
用するトークンはストアされ、他方パーサが使用しない
トークンたとえばコメントは廃棄される。

第８項目はトータルを表わすストリングの本体に終端文
字を含ませんのに用いる規則のタイプを示す。この項目
はたとえばストリングを走査する債に有益である。Ｃに
おいてはストリングを引用符によって区分けし、バック
スラッシュエスケープ文字として用いて引用符をストリ
ング中の文字として扱えるようにする。バックスラッシ
ュによって、スキャナはつぎの引用符がトークンの終端
でないことを判別する。Ｐａ５ｃａｌにおいては、スト
リング中に単一の引用符を含ませるのに、２つの継続す
る文字にシンボルを繰り返すようにしている。これら２
つの例は、終端包含規則項目の２つの実現可能な値を示
すものである。すなわち二重操作子（Ｐａｓｃａｌにお
いて）および特殊操作子（Ｃにおいて）である。

字句走査は新たな字句オブジェクトの第１文字をリスト
中の各字句要素の最初の文字とマツチングさせることに
よって行う。このマツチングは−致が判別されるまで行
われる。つぎに、継続する文字が走査され、本体文字の
組に対してマツチングされる。このマツチングは、区切
りすなわち終端文字の集合の要素たる文字に到達するま
で行う。

この時点では字句オブジェクト中の最後の文字が終端文
字集合と比較されていることになるる字句オブジェクト
が有効であれば字句要素タイプに応じたトークンが生成
される。これが、構文チエツクに必要なすべてである。

ただし、ユーザとしては、この時点でサブルーチンを付
加してトークンを個別に識別し、シンボル・テーブルに
挿入してトランスレータのコード生成部で利用できるよ
うにすることを望であろう。

表３は各構文グラフ・ノード（表１の第９項目）中に含
まれる情報を示す。ノード・タイプ要素はノードのタイ
プを記述し、他方ノード値要素は関連する値を付与する
。好ましい実現例では４つのノード・タイプがある。す
なわち「意味」　：この場合のノード値は意味機能リス
ト・オブジェクト（表１の第８項目）へのインデックス
である、「予約語」　：この場合のノード値は辞書オブ
ジェクト（表１の第１項目）へのインデックスである、
「字句要素名」　：この場合のノード値は字句トークン
のタイプであり、これ自体構文文法中の終端要素である
、「非終端」　：この場合のノード値は文法ゴール・オ
ブジェクト（表１の第６項目）へのインデックスであり
、これが構文グラフへのエントリ点を与える。

聚ｙ １）ノード・タイプ ２）ノード値 ３）次ノードへのポインタ ４）代替ノードへのポインタ 表３の第３および第４のオブジェクトはポインタである
。現行トークンが当該ノードに予定されるトークンと一
致すると次ノードへのポインタが辿られる。現行トーク
ンが当該ノードに示されるトークンと一致しなければ代
替ノードへのポインタが辿られる。

第４図はどのように構文グラフ・ノードを用いて構文グ
ラフを構築するかを示す。第４図は単純な構文グラフの
わずかな部分を示すにすぎない。

第４図は各オブジェクト６０〜７６は１個の構文グラフ
・ノード（表１の第９項目）を表わす。各ノードは２つ
のポインタを含み、これらは表３の項目３および４に対
応する。各オブジェクトの上側のポインタは次ノードへ
のポインタであり、下側のポインタが代替ノードへのポ
インタである。

ＮＩＬ　（突）へのポインタは次リンクがないことを示
す。

構文グラフはグラ・ノードのタイプをチエツクしてトラ
バースされる。ノード・タイプが予約語または字句名で
あると、字句トークンを読み出して、当該ノードに予定
されている値と比較される。

トークンを構文グラフ中のノードと比較する処理は構文
ノード・タイプに応じて変化する。ノード・タイプが予
約語であればトークンは値フィールドに示される正確な
予約語でなけばならない。ノード・タイプが字句基であ
れば、トークンは値フィールドに示されるタイプの字句
でなければならない。

ノード・タイプが意味であれば、当該ノードに関連する
機能が呼び出され、パースが進行すべきか停止すべきか
を示す結果が返される。意味機能はまた非意味の作用た
とえばトークンをシンボル・テーブルに配置したり、シ
ンボル・テーブルと比較したり、変数タイプへ割り当て
たり変数タイプを比較したり、という作用または他の意
味解析やコード生成機能を実行する。

ノード・タイプが非終端であれば、グラフの現行位置が
スタックに挿入され、当該値フィールドに示されるグラ
フ位置にジャンプがなされる。このジャンプはサブゴー
ルを示す。サブゴールが終了すると（所定の次ノード・
ポインタ・フィールドのＮＩＬに到達したことにより表
わされる）現行位置がスタックから取り出され、次ノー
ド・ポインタが辿られて処理が続けられる。サブゴール
自体は再起的に付加的なサブゴールを生成してもよい。

サブゴールへジャンプが行われると、１つの位置にスタ
ックに挿入され、復帰時にその位置がスタックからポツ
プする。プログラムに構文エラーがなければ、最後のト
ークンが読まれた時点でスタックは空となる。

第４図において、構文グラフ中の現行ノードがノード６
０と仮定しよう。そうすると最初のトークンがノード６
０のノード・タイプおよびノード値に比較される。トー
クンが一致すると、構文グラフが辿られてノード６２に
到り、第２のトークンがノード６２と突き合わされる。

ここで一致が判明すると、グラフが辿られてノード６２
に到り、次のノードが突き合わされる。ノード６４から
の次ノード・ポインタがＮＩＬをポンイトし、この結果
、このノードにおける突き合わせの成功によってグラフ
の当該トラバースが終了することを示される。ノード６
２および６４に対する代替ノード・ポインタはともにＮ
ＩＬをポンイとし、この結果代替がないことが示される
。適切なトークン＝２３− がノード６２ともノード６４とも一致しなければ、代替
ノードがないということによって構文エラーが起こって
いることが示される。

ノード６０はノード６６に対する代替ノードを有する。

したがって、もし最初のトークンがノード６０と一致し
ないのであれば、この最初のトークンはノード６６と比
較されることになる。このトークンがノード６６と一致
しなければ、代替ノードポインタを辿ってノード６８に
到り、比較が行われ、さらにグラフにわたって処理が続
けられる。最初のノードがノード６６と一致すると、次
のトークンがノード７０と比較され、さらに次トークン
がノード７０と一致すると第３のトークンがノード７２
と比較される。これは上述と同様である。第２のトーク
ンがノード７０と一致しなければ代替ノード・ポインタ
により、第２のトークンをノード７０と突き合わせなけ
ればならないことが示される。ノード７４との突き合わ
せが成功すると、第３のトークンがノード７６比較され
る。

上述のシステムによれば、トランスレータが対象とする
入力言語が何であろうと、既知の態様で操作される標準
オブジェクト組を提供できる。したがって、字句スキャ
ニングおよびパージングを入力言語について実行するの
に、入力言語の特別な知識を必要とすることがない。言
語の特別な情報はすべて標準オブジェクトにストアされ
る値に入れ込まれる。したがって、たとえば入力言語の
構文は、ストアされるデータと、初期化された構文グラ
フのノードとの相互関係によって完全に定義される。１
つの構文グラフを他の構文ダラムに置き換えることによ
って、パージング・ルーチンに悪影響を与えることなく
新しい入力言語を定義できる。単にデータが変更される
だけである。

Ｆ１発明の詳細 な説明したように、この発明によれば入力言語の仕様を
目的言語の一組のオブジェクトに変換し、これらオブジ
ェクトを目的言語のプログラム・コードと結合して入力
言語用のトランスレータを生成するようにしているので
、トランスレータのうちユーザが記述すべき部分と簡易
にインターフエースを行いながらトランスレータのソー
ス・コードの部分を自動的に生成でき、さらに仕様変更
に簡易に対処できる。

【図面の簡単な説明】

第１図はこの発明の実施例を示すブロック図、第２図は
第１図実施例を説明するフローチャート、第３図は上述
実施例の字句スキャナで用いるデータ構造を示す図、第
４図は上述実施例のパーサで用いるデータ構造を示す図
である。 １０・・・・・・メタ言語ソース・ファイイル、１２・
・・・・メタ言語トランスレータ、１４・・・・・・目
的言語オブジェクト、１６・・・・・・ユーザ・ソース
・ファイル。 １８・・・・・・目的言語トランスレータ、２０・・・
・・・入力言語トランスレータ、２２・・・・・入力言
語ソース・ファイル、２４・・・・・・変換済み入力言
語ファイル。 出願人　　インターナショナル・ビジネス・マシーンズ
・コーポレーション 復代理人　弁理士　澤　１）俊　夫

Claims (2)

【特許請求の範囲】
1. （１）入力言語の仕様を生成するステップと、上記入力
   言語の仕様を目的言語の一組のオブジェクトに変換する
   ステップと、 上記オブジェクトと、目的言語で独立して生成されたコ
   ードとを結合するステップと、 上記コードを実行可能な形態に変換して入力言語トラン
   スレータを生成するステップとを有することを特徴とす
   るプログラム言語トランスレータ生成方法。
2. （２）入力言語の字句および構文の仕様を含む第１のソ
   ース・ファイルと、 上記第１のソース・ファイルを目的言語の複数のオブジ
   ェクトに変換し、これらオブジェクトによって上記入力
   言語の字句および構文の構造を定義する第１の変換手段
   と、 上記目的言語のプログラム・コードを含む第２のソース
   ・ファイルと、 上記目的言語のプログラム・コードおよび目的言語のオ
   ブジェクトを単一の実行可能ファイルに変換して上記入
   力言語用のトランスレータとする第２の変換手段とを有
   することを特徴とするプログラム言語トランスレータ生
   成装置。