JP2002525744A - テキスト・オブジェクトのコンパイル方法およびシステム - Google Patents

Abstract

(57)【要約】 機械語のコードでない２進オブジェクトおよびテキスト・オブジェクトを発生することができるテキスト・オブジェクト・コンパイラおよび言語。任意のテキストまたは２進フォーマットで情報の目的ファイルを生成するオブジェクト指向のコンピュータ言語であって、ファイルは“ｐａｇｅ”としてプログラマによって定義され、ファイルのロケーションが“ｔａｒｇｅｔｓ”としてプログラマによって定義される。コンパイラは言語をコンパイルして任意の各種の出力を発生し、その出力はテキスト・フォーマット（ＨＴＭＬ、ＳＧＭＬ、および他のスクリプト言語など）および２進フォーマット（グラフィック画像、２進データ、または他のマルチメディア情報など）を含む。

Description

【発明の詳細な説明】

【０００１】 （発明の分野） 本発明は、ソフトウェア・コンパイラの分野に関し、特に、１つまたはそれ以
上のソース・ファイルから情報のファイルを生成する方法に関する。

【０００２】 （関連技術の説明） １９８９年３月に、Ｅｕｒｏｐｅａｎ Ｌａｂｏｒａｔｏｒｙ ｆｏｒ Ｐａ
ｒｔｉｃｌｅ Ｐｈｙｓｉｃｓ（粒子物理学のためのヨーロッパ研究所）または
ＣＥＲＮ（Ｃｏｎｓｅｉｌ Ｅｕｒｏｐｅｅｎ ｐｏｕｒ ｌａ Ｒｅｃｈｅｒ
ｃｈｅ Ｎｕｃｌｅａｉｒｅ）がワールド・ワイド・ウェブ（ＷＷＷ、または単
に「ウェブ」）を開発した。それは１つのコンピュータ上のユーザが他のコンピ
ュータ上に格納されている情報に世界中のネットワークを経由してアクセスする
ことができるインターネット・ベースのコンピュータ・ネットワークである。ウ
ェブ・ブラウザとして知られている直感的なユーザ・インターフェースにより、
ウェブは急速にテキストおよび２進情報の送信およびアクセスのための方法とし
て普及した。それ以来、ワールド・ワイド・ウェブ・サイトの数、およびウェブ
上に置かれる情報の量が爆発的に増えてきている。

【０００３】 電子ファイル、文書、画像、音声および他のフォーマットの形式での情報が、
インターネットおよびウェブ・コンテンツのベースを形成し、有用で意味のある
ウェブ・サイトを生成するための重要な要素となっている。

【０００４】 ウェブ上に情報を置くためには、その情報は「ファイル」の中に２進フォーマ
ットまたはテキスト・フォーマットで格納されなければならない。バイナリ文書
は格納される情報によって変わる既知のフォーマットで保存されている。例えば
、二次元画像は“Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇ
ｒｏｕｐ”（ＪＰＥＧ）または“Ｇｒａｐｈｉｃａｌ Ｉｍａｇｅ Ｆｏｒｍａ
ｔ”（ＧＩＦ）の標準フォーマットで格納されることが多い。音声ファイルおよ
び動画像には、同様に他のフォーマット、例えば、“ＷＡＶ”、“ＭＯＶ”、お
よび“ＭＰＥＧ”などのフォーマットがある。テキスト文書の場合、文書は、Ｈ
ｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＨＴＭＬ）のフォーマッ
トで格納される。ＨＴＭＬフォーマットはウェブのテキスト文書（“ウェブ・ペ
ージ”とも呼ぶ）の体裁および構造を指定する。

【０００５】 これらのフォーマットは、ウェブ・ブラウザに対する互換性を生成するために
必要であるが、これらの固定されたフォーマットでウェブ・サイトを変更し、情
報を更新することは困難であり、時間が掛かる。例えば、すべてのウェブ・ペー
ジに著作権の注意書きがあると仮定する。すべてのページ上の著作権の注意書き
を更新するには、ウェブ・サイトの管理者が手ですべてのページを変更するか、
あるいはグローバル・サーチ・アンド・リプレースの方法を使用しなければなら
ない。しかし、いくつかのウェブ・サイトでの方法が一様でないために、グロー
バル・サーチ・アンド・リプレースは使用できない可能性がある。もっと複雑な
ウェブ・ページの変更、例えば、“アプレット”として知られている小規模アプ
リケーションを変更することもさらに困難である。更新することができる単独の
ロケーションまたはファイルがあって、その変更がウェブ・サイト全体に対して
、あるいは適切なウェブ・ページだけに対して伝播する場合はまだよい。ごく単
純に云えば、大量のデータを任意のフォーマットで維持および生成する非常に単
純な問題は、困難であり、非常に時間が掛かる。

【０００６】 いくつかの解決策が提案されており、それぞれ問題がある。 特定のウェブ開発者は、“ｗｈａｔ ｙｏｕ ｓｅｅ ｉｓ ｗｈａｔ ｙｏ
ｕ ｇｅｔ”（ＷＹＳＩＷＹＧ）なウェブ・ページ・エディタによりウェブ・ペ
ージを生成することを選定する。そのようなエディタは、ページの設計を単純化
するグラフィック・インターフェースを通してウェブ・ページをアセンブルする
が、その結果は制限される。何故なら、それはその情報を維持するためのニーズ
を解決しないからである。上記の例を使用して、すべてのページ上での著作権の
注意書きを更新するには、ウェブ・サイトの管理者が、ウェブ・ページを個々に
編集しなければならないか、あるいはウェブ・ページ・エディタのプログラムが
グローバル・サーチ・アンド・リプレースの方法を使用することもできる。

【０００７】 代わりに、ＨＴＭＬファイルをアセンブルするために単純なプリプロセッサ・
プログラムが使用されている。そのようなプリプロセッサによってウェブ・ペー
ジ設計者は、文書を前処理し、リストされている文書をマスタ文書の中に挿入す
ることができる。例えば、“ｆｏｏ．ｄｏｃ”と呼ばれる別のリストの文書ファ
イルをマスタ文書の中に含めるために、ウェブ・ページ設計者は次のようにタイ
プすることができる。

【０００８】 ＃ｉｎｃｌｕｄｅ “ｆｏｏ．ｄｏｃ” そうすると、そのリストされた文書が含められる。これによって共通のＨＴＭＬ
コードのフラグメントを文書の中に挿入することができるが、ウェブ・サイトが
成長し、より多くのページがそのサイトに追加されるにつれて、そのようなシス
テムのメンテナンスが急速にロジスティック上の悪夢となる。また、そのフラグ
メントは、それらが文書の中に含められているポイントにおいて再定義すること
ができない。さらに、そのようなシステムは、テキスト・ベースの文書に厳密に
制限され、２進形式の情報を扱うことはできない。

【０００９】 引用によって本明細書の記載に援用する「文書管理および生産システム」とい
う名称のスミス他の、１９９３年１月１９日発行の米国特許第５，１８１，１６
２号は、文書を、オブジェクト指向のコンピュータ環境において独立した「オブ
ジェクト」として格納される論理構成要素に分解するシステムを開示している。
そのようなシステムは、その文書がプリントされ、電子的に表示され、あるいは
電子的に伝送されるたびに発生する関係データベースに対する問合わせに依存し
ている。ページを１分間に数千回送信することができるウェブ・サイトの場合、
この解決策は、そのウェブ・サーバの演算リソースにおいて重荷となる。結果と
して、そのシステムは、低速であり、そのような要求度の高い環境に対しては有
効性が限定されたものになる。同様に、クライアント・マシン上で数ページの情
報を配送するために関係データベースを使用することが試みられてきている。こ
れはそのクライアント・マシンに対してそれらが配送される時に文書の動的な構
造を提供するが、この解決策もページ情報を絶えず再生しなければならないので
、サーバの演算リソースに対して重荷となる。キャッシングによって生成される
ページは、その演算リソースの問題をある程度解決することができるが、キャッ
シュされたページは古くなる可能性があるので、新しい問題が発生する。

【００１０】 すべてを本明細書の記載に援用するいくつかの関連特許、すなわち、１９９７
年９月１６日付けのゴスリングの、米国特許第５，６６８，９９９号（「バイト
・コードのプログラム・ループの中でのスタックの使用の予備検証のためのシス
テムおよび方法」）、マックマニスの米国特許第５，６９２，０４７号（「信頼
されるソースからの検証不能なプログラムを使用するためのファシリティによる
検証可能なプログラムを実行するためのシステムおよび方法」）および、フォー
リー他の、米国特許第５，７０６，５０２号（「インターネット・イネーブル型
のポートフォリオ・マネージャのシステムおよび方法」）も、この問題を解決す
ることができない。まとめて、これらの特許はクライアントのワークステーショ
ン上で遠隔でアプリケーションを実行するためにバイトコード言語で書かれたコ
ンピュータ・プログラムの保全性を検証する方法およびシステムを開示している
。この解決策は動的なクライアント・マシン・アプリケーションを生成すること
ができるが、それはシステムの中で情報を維持することの問題を解決しない。

【００１１】 必要なものは、異なるファイル・フォーマットのファイルを生成することがで
き、しかも維持することが容易である２進およびテキストの両方の情報を処理す
る、より柔軟性のある方法である。

【００１２】 本発明の、「テキスト・オブジェクト・コンパイラ」の方法によって、ユーザ
は情報を抽象化し、実質的に任意のファイル・フォーマットで情報を作り出すこ
とができる。

【００１３】 現代のほとんどすべてのコンピュータは、機械語に対して応答するレジスタ・
ベースのノイマン型コンピュータである。これらの機械語はレジスタの内容につ
いて演算する命令を含む。元々、コンピュータのソフトウェア命令は、機械語の
操作に関して編成されていた。コンピュータがさらに複雑になるにつれて、機械
語でのプログラミングが困難になり、ますます厄介なものになってきた。結果と
して、コンピュータ科学者は機械命令を抽象化し、式および手順に関して構築さ
れたソース言語として知られている高級言語を生成した。ソフトウェアが進化す
るにつれて、ソース言語を機械語での命令に変換するための２つの戦略、すなわ
ち、インタプリタおよびコンパイラが開発された。

【００１４】 ネイティブ機械語で書かれたインタプリタは、コンピュータがソース言語の１
つで書かれているプログラムを実行するように構成する。ソース言語の基本的な
演算子またはコマンドが与えられたマシンのネイティブ機械語で書かれたサブル
ーチンのライブラリとして実装されている。インタプリタはソース言語を１つず
つ読み取り、その指定された操作を実行する。解釈されるべきプログラム、すな
わち、ソース・プログラムは、データ構造として表現されている。インタプリタ
は、そのデータ構造を移動し、そのソース・プログラムを分析する。その際、コ
ンピュータはライブラリから適切な基本操作を呼び出すことによって、そのソー
ス・プログラムの意図された挙動をシミュレートする。

【００１５】 ソース・プログラムを分析して実行時に機械語に変換する代わりに、プログラ
ム実行の前にこれらのタスクを実行し、より効率的なプログラム実行を可能にす
ることができる。このソース言語を命令に変換する代わりの方法がコンパイルと
呼ばれている。ソース・プログラムを分析して、そのソース・プログラムを機械
語に戻すプログラムはコンパイラと呼ばれる。図１に示されているように、与え
られたソース言語およびマシンに対する伝統的な（すなわち、従来の技術の）コ
ンパイラ２は、ソース・コード１（すなわち、高水準「コンピュータ言語」で書
かれたプログラム）を、この分野の技術においては「機械語」として呼ばれてい
るオブジェクト・コード３、すなわち、そのコンピュータのネイティブ言語で書
かれたプログラムに変換する。

【００１６】 図２によって示されている従来のコンパイラ２は、語いアナライザ１０、パー
ザ２０、およびコード・ジェネレータ３０から構成されている。語いアナライザ
１０は、コンピュータのソース・コード１を取り、そのコードを語いトークンに
分解する。そのような語いトークンは関連の高級コンピュータ言語における命令
または他のキーワードに基づくことができる。パーザ２０は、そのトークンを取
り、それらをソース言語およびコンピュータのソース・コード１によって設定さ
れている関係に基づいて論理的にグループ化する。最後にコード・ジェネレータ
３０はパーザ２０によって設定されたその関係を取り、それらをコンピュータの
機械語での実行可能なコンピュータ・オブジェクト・コード３に変換する。

【００１７】 従来のコンパイラは、引用によって本明細書の記載に援用する米国特許第５，
５６０，０１５号（１９９６年９月２４日付けのオノデラの、「コンパイラおよ
びコンパイル方法」）、米国特許第５，４４２，７９２号（１９９５年８月１５
日付けのチョンの、「エキスパート・システムのコンパイル方法」）、および米
国特許第５，７６８，５９２号（１９９８年６月１６日付けのチャンの、「プロ
ファイル・データを管理するための方法および装置」）などの従来の技術におい
て周知である。

【００１８】 従来のインタプリタおよびコンパイラは、コンピュータの高級言語のソース・
コードをコンピュータ上で実行されるオブジェクト・コードに変換する。実効的
に、インタプリタおよびコンパイラによって、コンピュータのプログラマは高レ
ベルの抽象化されたコンピュータ・プログラムを作成し、オブジェクト・コード
を生成することができる。

【００１９】 （発明の概要） 本発明の「テキスト・オブジェクト・コンパイラ」（ＴＯＣ）の方法およびシ
ステムは、コンピュータ・プログラムに対して従来のコンパイラが適用するのと
同じレベルの情報に対する抽象化を適用する。ユーザは、機械語のオブジェクト
・コードではない抽象的なソース・コードを設計し、それが１つのファイルまた
は複数のファイルにコンパイルされる。代わりに、ＴＯＣはテキストまたはバイ
ナリ・ファイルなどの実質的に任意の情報フォーマットで情報を発生する。ＴＯ
Ｃは、「テキスト・オブジェクト言語」（ＴＯＬ）としてＡＳＣＩＩテキストで
書かれた１つまたはそれ以上のソース・ファイルを読み出し、そのソース・ファ
イルを任意の文書フォーマットでの１つまたはそれ以上の出力ファイルに処理す
る。そのコンパイル・プロセスは、ソース・ファイルの中の情報を出力の文書フ
ォーマットに再編成し、文書生成プロセスを容易化するために、コンパイル時の
ユーティリティ・コマンドを含むことができる。

【００２０】 第１の実施形態においては、語いアナライザがＴＯＬの正規表現で書かれたソ
ース入力をトークン化し、トークン表現のソース入力を作り出す。そのようなＴ
ＯＬの式は、変数、関数、およびクラスを含むことができる。パーザはトークン
間の関係を決定し、ページ・ジェネレータが、そのトークンとトークン間の関係
を評価して出力を発生することができるようにする。その結果の出力をソース入
力によって指定された目的ロケーションにおいてファイルとして書き込むことが
できる。

【００２１】 本発明のもう１つの態様においては、ソース入力が語いに分析されて、そのソ
ース入力の正規表現を表しているトークンが作られる。その正規表現はテキスト
・オブジェクト言語で書かれ、変数、関数およびクラスを含むことができる。そ
の正規表現が構文解析されてトークン間の関係が決定される。例えば、トークン
間の任意のクラス関係が、このステップの中で決定される。最後に、そのトーク
ンおよび関係が評価されて非実行可能出力が発生される。その非実行可能出力が
次にファイルに書き込まれる。そのファイルのロケーションは、指定の目的ロケ
ーションとして元のソース入力によって指定することができる。

【００２２】 本発明のこの好適な実施形態においては、テキスト・オブジェクト言語の正規
表現で書かれたソース入力が先ず最初に読み込まれる。その正規表現はそのプロ
セスの出力を決定するために使用されるページ定義を含んでおり、そしてさらに
変数、関数、ターゲットのロケーションおよびオブジェクト指向のクラスを含む
ことができる。読み込まれると、ソース入力は語いに分析されて、その正規表現
のトークン表現が作り出され、それはページ定義から発生されたトークンを含む
。そのトークンが構文解析されてトークン間の関係が決定され、その結果の関係
がコンピュータ・メモリの中で作られる。各変数および関数が評価され、それら
の値が決定される。その決定された値がそれぞれの対応しているコンピュータ・
メモリの中の変数または関数のトークンを置き換える。次に、ページのトークン
のコンピュータ・メモリ表現に基づいた非実行可能ファイルが、ソース入力の中
で指定された目的ロケーションにあるファイルに対して書き込まれる。

【００２３】 本発明の上記および他の目的、特徴、および利点が、添付の図面を参照しなが
ら以下の詳細な説明を読めばより容易に理解することができるだろう。 （発明の詳細な説明） テキスト・オブジェクト・コンパイラは、実行可能ファイルを生成するために
プログラミング言語において普通に使用されている各種の既存のプログラミング
およびコンパイラの方法を使用する。ＴＯＣの一意な側面は、それが非実行可能
ファイルを生成することに対して適用されることである。その非実行可能ファイ
ルは「ターゲット・ドキュメント」と呼ばれる。図３に示されているように、テ
キスト・オブジェクト言語（ＴＯＬ）で書かれているソース・ファイル１０１が
、ＴＯＣ１０２によってコンパイルされ、出力としてターゲット・ドキュメント
１０３が作られる。そのターゲット・ドキュメントのロケーションは、プログラ
マが定義することができ、そのロケーションは「目的ロケーション」と呼ばれる
。ターゲット・ドキュメント１０３は、任意のタイプのフォーマットであってよ
く、また、他のコンパイラまたはプログラムによって使用される他のソース・フ
ァイルを作り出すことさえもできる。ＴＯＣ１０２は、ターゲット・ドキュメン
ト１０３のフォーマットに関しては実際には何も知らない。そのターゲット・ド
キュメントのフォーマットは専らプログラマに任されている。

【００２４】 ここで、添付図面で示されている本発明の好適な実施形態を詳細に参照する。
本発明はその好適な実施形態に関して説明されるが、それらは本発明をそれらの
実施形態に限定することが意図されているのではないことを理解されたい。反対
に、本発明は付記されている特許請求の範囲によって定義されている本発明の精
神および範囲内に含めることができる代替案、変更および等価物を含むことが意
図されている。

【００２５】 テキスト・オブジェクト言語（ＴＯＬ） この好適な実施形態においては、１つまたは複数のソース・ファイルは、テキ
スト・オブジェクト言語で書かれており、それはコンパイルまたは解釈されて、
少なくとも１つの目的ファイルが結果として作られる。ＴＯＬの演算子のいくつ
かのリスティングが表１に提供されている。

【００２６】

【表１】 表１． ＴＯＬの演算子 ＴＯＬは、他のプログラミング言語に似ており、変数、クラス、関数およびサ
ブルーチンを備えているが、ＴＯＣ１０２によってのみ認識される言語構文を使
用する。さらに、ＴＯＬの演算子に対して、いくつかのコンパイル時のユーティ
リティ・コマンドが、文書生成プロセスを容易化するために存在する。

【００２７】

【表２】 表２． ＴＯＬのコンパイル時のユーティリティ・コマンド 表１のテキスト・オブジェクト言語で書かれているソース・ファイルの一例１
０１が表３に示されている。

【００２８】

【表３】 表３． テキスト・オブジェクト言語で書かれているソース・ファイルの例（
“ｍｙｓｏｕｒｃｅ．ｔｘｔ”）

【００２９】 表３のテキスト・オブジェクト・コードのソース・ファイル１０１の例の中で
示されているように、ＴＯＬの５つの一次構成要素、すなわち、クラス、変数、
関数、ページ、およびターゲットがある。クラス、変数、および関数の概念は従
来の技術のコンピュータ言語の中に存在するが、テキスト・オブジェクト言語の
中にはそのほかにページおよびターゲットの概念が存在する。

【００３０】 ＴＯＬのクラスは普通のオブジェクト指向プログラミング（ＯＯＰ）のクラス
に似ていて、その要素の多くを共有する。クラスによって、文書のプログラマは
、そのソース・ファイル全体を通じて再使用することができて任意の目的ファイ
ルに対して適用されるオブジェクトに、文書のセクションを編成することができ
る。クラスの指定はオプションである。何故なら、デフォールトのクラス、すな
わち、“ｂａｓｅ ｃｌａｓｓ”が常に仮定されるからである。「派生された」
または「子供」のクラスは、そのベースまたは「親」のクラスのすべての変数お
よび関数を継承する。

【００３１】 クラスはｐｕｂｌｉｃ、ｐｒｉｖａｔｅ、またはｐｒｏｔｅｃｔｅｄがあり得
る。ｐｕｂｌｉｃのクラスによってそれぞれの関数および変数を他のクラスによ
って再定義することができる。デフォールトでは、すべてのクラスがｐｕｂｌｉ
ｃである。ｐｒｉｖａｔｅのクラスによってそれぞれの関数および変数を他のメ
ンバまたはｆｒｉｅｎｄクラスによってのみ再定義することができる。ｐｒｏｔ
ｅｃｔｅｄのクラスによってその変数および関数がメンバ関数、それが宣言され
ているクラスのｆｒｉｅｎｄ、およびその保護されているクラスから派生したク
ラスのメンバ関数およびｆｒｉｅｎｄによって使用されるようにすることができ
る。さらに、１つのクラスが他のクラスをｆｒｉｅｎｄとして宣言することがで
きる。ｆｒｉｅｎｄクラスには、その宣言しているクラスの変数および関数のす
べてに対するｐｕｂｌｉｃアクセスが与えられている。

【００３２】 変数によって、ソース・ファイルのプログラマはターゲット・ドキュメントの
要素を参照によって表すことができ、そしてその参照を使用して、その実際のデ
ータを使用するのではなく、セクションまたはターゲット・ドキュメントを生成
することができる。クラスと同様に、この好適な実施形態においては、変数はｐ
ｕｂｌｉｃ、ｐｒｉｖａｔｅまたはｐｒｏｔｅｃｔｅｄがあり得る。また、変数
をｖｉｒｔｕａｌとし、それらを派生されたクラスの中で定義させることができ
る。しかし、変数がｖｉｒｔｕａｌと宣言されると、その変数のすべての継承さ
れたクラス・インスタンスはｖｉｒｔｕａｌである。そのクラスのｖｉｒｔｕａ
ｌ変数は、その派生された（子供の）クラスによってそのｖｉｒｔｕａｌ変数が
定義されるまで、そのプログラムの内部には存在することができないことに留意
されたい。

【００３３】 関数はいくつかの計算をカプセル化するための便利な方法であり、その実行に
関して煩わされることなく使用することができる。関数によって、プログラマが
詳細に関して煩わされることなしに概念的な方法で再帰型のプロシージャを抽象
化することができる。関数は代表的なプログラミングのサブルーチンに似ている
。クラスおよび変数と同様に、関数にはｐｕｂｌｉｃ、ｐｒｉｖａｔｅ、または
ｐｒｏｔｅｃｔｅｄがあり得る。

【００３４】 関数名のオーバローディングによって、異なる引数タイプについての共通の演
算を提供する複数の関数インスタンスが共通の名前を共有することができる。い
くつかの関数が同じ名前を共有するが、それぞれの変数の数が異なっているよう
に関数をオーバロードすることができる。オーバロードされた各関数は、一意な
個数の変数を備えていなければならず、それによってコンパイラは、そのオーバ
ロードされた関数の各インスタンス間の識別を行うことができる。関数をｖｉｒ
ｔｕａｌとし、それらを派生された（子供の）クラスで定義させることができる
。関数がｖｉｒｔｕａｌと宣言されると、その関数のすべての派生されたクラス
のインスタンスはｖｉｒｔｕａｌである。ｂａｓｅｃｌａｓｓのｖｉｒｔｕａｌ
関数も、その派生された関数によって継承される場合に、その派生されたクラス
の中でもｖｉｒｔｕａｌである。そのような関数は抽象クラスとして扱われ、そ
のクラスのオブジェクトは、その関数が派生されたクラスによって定義されるま
で、そのプログラムの内部には存在することができない。

【００３５】 ｐａｇｅはテキスト・オブジェクト言語にとって一意である。ｐａｇｅのパラ
メータは、ソース・ファイル１０１を実際の個々のターゲット・ドキュメントの
１０３に組み合わせるか、あるいは構文解析する方法をテキスト・オブジェクト
・コンパイラ１０２に知らせる。ｐａｇｅは結果のターゲット・ドキュメント１
０３の開始点および終了点を定義し、ターゲット・ドキュメント１０３の内容を
定義する。

【００３６】 ｔａｒｇｅｔｓもテキスト・オブジェクト言語にとって一意である。ｔａｒｇ
ｅｔのパラメータは、ターゲットのロケーションを定義する。定義されると、そ
のｔａｒｇｅｔのパラメータは、そのターゲット・ドキュメントを置く場所につ
いてテキスト・オブジェクト・コンパイラ１０２に知らせる。このロケーション
は「目的ロケーション」と呼ばれる。目的ロケーションはＴＯＣ１０２を実行し
ているコンピュータにとってローカルであってよく、あるいはそのコンピュータ
によってコンピュータ・ネットワーク上でアクセスすることができる遠隔地にあ
ってよい。ソース・ファイル１０１が、そのターゲット・パラメータによって複
数の目的ロケーションを定義する場合、ＴＯＣ１０２は各目的ロケーションにお
いて同一のターゲット・ドキュメント１０３を生成する。複数のターゲットは、
実験的な出力を生成すること、冗長の目的のためにバックアップ・ファイルを生
成すること、そしてメイン／プロダクションのサーバのファイルを更新すること
のために有用である。例えば、プログラマは２つのターゲットを定義して一次ウ
ェブ・サイトおよびその「ミラー」ウェブ・サイトを代わりのロケーションにお
いて生成することができる。ターゲット・パラメータがテキスト・オブジェクト
のコード１０１から省略された場合、そのターゲット・ドキュメント１０３はデ
フォールトのローカル・ロケーションに生成される。

【００３７】 テキスト・オブジェクト・コンパイラ（ＴＯＣ） テキスト・オブジェクト・コンパイラ１０２は、テキスト・オブジェクト言語
のソース・ファイル１０１のコンパイルを実行し、結果としてそのターゲット・
パラメータによって定義されている目的ロケーションにおいて出力としてｐａｇ
ｅのパラメータによって定義されているターゲット・ドキュメント１０３を生成
する。説明されたように、ターゲット・ドキュメント１０３は、任意のフォーマ
ットであってよい。これはオブジェクトの機械語のコード、すなわち、実行可能
ファイルだけを生成する従来の技術のソフトウェア・コンパイラからＴＯＣ１０
２を区別することに留意されたい。しかし、プログラマはそれぞれのソース・プ
ログラム・コード１０１によってそのファイルの出力フォーマットを定義するこ
とに留意されたい。

【００３８】 ここで、ＴＯＣの構造および方法について注目する。 ＴＯＣ１０２はその構造において従来のコンパイラと似ている。従来のコンパ
イラと同様にＴＯＣは語いアナライザ１０およびパーザ２０を含む。しかし、Ｔ
ＯＣと違って、図２に示されている従来のコンパイラは、パーザの出力をコンピ
ュータのコード・ジェネレータ３に対して供給し、実行可能なコンピュータ・オ
ブジェクト・コード３を生成する。図４に示されているように、テキスト・オブ
ジェクト・コンパイラ１０２においては、パーザ２０の出力がページ・ジェネレ
ータ２００に対して与えられ、ターゲット・ドキュメント１０３が出力として発
生される。

【００３９】 ＴＯＣの語いアナライザ１０は、従来のコンパイラの語いアナライザと同様な
方法で式を検査する。この「トークン」として知られているユニットへの分割は
、この分野の技術において「語い分析」として知られているプロセスである。本
質的に、語いアナライザは、正規表現を探す。正規表現はコンピュータの言語を
使用しているパターン技術である。語いアナライザは、できるかぎりのマッチす
る正規表現を実行し、そしてソース・ファイル全体のテキストをトークンに分類
しようとする。テキスト・オブジェクト言語においては、その式は変数名、関数
名、クラス名、目的ロケーション、ページ定義、定数、文字列、演算子、句読点
などを含むことができる。例えば、表３の中のソース・ファイルをコンパイルす
る時、コンパイラは最初に既知の演算子（表１にリストされている）の各インス
タンスを既知のトークンとして最初に分類する。しかし、そのワードまたは式が
コンパイラにとって未知のものであった場合、それはやはりトークン化されるが
、その値または関係はパーザによって決定されなくてはならない。

【００４０】 入力がトークンに分割される際、コンパイラはそのトークン間の関係を確立し
なければならない。テキスト・オブジェクト・コンパイラは、式、ステートメン
ト、宣言、ブロック、関数／プロシージャ、クラス構造、およびプログラムの中
のページを見つける必要がある。それは「パージング」として知られているプロ
セスである。コンパイラが理解する関係を定義する規則のリストは文法と呼ばれ
る。一例のテキスト・オブジェクト言語の文法が上記の表１に示されている。

【００４１】 テキスト・オブジェクトのコンパイル・プロセスは例を示すことによって最も
よく説明される。表３の中の例などの既存のソース・ファイル１０１がテキスト
・オブジェクト言語で書かれている。コンパイラは図５のステップ２５０に示さ
れているように、ソース・ファイルを読み取る。そのソース・コードをコンパイ
ルするプロセスにおいて、コンパイラは２つのタスクを何度も繰り返し実行する
。それらは、ａ）入力のソース・コードを意味のあるユニットに分割するタスク
（ステップ２６０）および、ｂ）そのユニット間の関係を発見するタスク（ステ
ップ２７０）である。これらの２つのプロセスは、それぞれ「語い分析」（ステ
ップ２６０）および「パージング」（ステップ２７０）と呼ばれる。トークンの
関係を決定することができない場合、パーザは次にそのソース・ファイルが終り
に達したかどうかをステップ２８０において決定する。ソース・ファイルの終り
に達していた場合（ステップ２８０）、未決定のトークンは構文または使用法の
いずれかがエラーであり、ステップ２８２においてエラーがレポートされる。ソ
ース・ファイルが終りに達していなかった場合、コンパイラはステップ２５０へ
ループ・バックし、ソース・ファイルを読み取る。同様に、ステップ２７０のパ
ージングが正常に行われ、ステップ２８４によって決定されるようにファイル全
体がまだ終りに達していなかった場合、コンパイラはステップ２５０においてソ
ース・ファイルのラインをさらに読み取る。

【００４２】 語い分析およびパージングの一例は次の通りである。コンパイラは最初に表３
の第１ラインをステップ２５０において読み取る。各ワードがトークン化され、
そしてＴＯＬ演算子などの正規表現の既知のセットに対してマッチされる。最初
の既知の演算子、コメント演算子（“／／”）が識別２６０において識別される
。このＴＯＬ文法の実装によって定義されているように、そのラインの残りの部
分はコメントであると決定され、そしてコンパイラはステップ２７０においてそ
のラインの残りの部分を無視する。ソース・ファイルが終りに達していないこと
がステップ２８４によって決定されているので、コンパイル・プロセスが継続し
、コンパイラはステップ２５０においてソース・ファイルの次のラインを読み取
る。

【００４３】 語いアナライザは第２のラインに４つのトークン、すなわち、ワード“ｃｌａ
ｓｓ”、“ｍｙｃｌａｓｓ”、“：＝”および“ｂａｓｅｃｌａｓｓ”が存在す
ることをステップ２６０において知る。これらのトークンのうちの２つ、すなわ
ち、“ｃｌａｓｓ”および等号演算子（“：＝”）が演算子として識別され、第
３のトークン“ｂａｓｅｃｌａｓｓ”は“ｂａｓｅｃｌａｓｓ”のキーワードと
して識別され、それはＴＯＬのｂａｓｅｃｌａｓｓを定義する。トークン“ｍｙ
ｃｌａｓｓ”は、最初はその語いアナライザには知られていない。そのトークン
の情報がパーザに転送され、パーザはそのソース・ファイルがＴＯＬのｂａｓｅ
ｃｌａｓｓから下りてくる子供のクラス“ｍｙｃｌａｓｓ”を定義していること
をステップ２７０において理解する。パーザはメモリ・テーブル、メモリ・ツリ
ー、または等価なメモリ構造を構築してそのクラス構造を分類する。そのプロセ
スが次のラインについて繰り返され、図６によって示されているクラスの継承の
関係が分かる。クラスｍｙｃｌａｓｓ３１０がｂａｓｅｃｌａｓｓ３００から導
かれており、そしてクラスｎｅｗｃｌａｓｓ３２０は「親の」クラスｍｙｃｌａ
ｓｓ３１０から導かれた「子供の」クラスである。そのｎｅｗｃｌａｓｓのクラ
スを反映するようにメモリ・ツリーが拡張される。

【００４４】 コンパイラは表３の中の次のいくつかのラインを処理する。それらは変数“ｔ
ｉｔｌｅ”に対する変数定義から構成されている。その変数が構文解析され、メ
モリ・ツリーの中に格納され、それぞれの適切なクラス定義に対して図７で示さ
れているようにリンクされる。ｂａｓｅｃｌａｓｓ３００には変数“ｔｉｔｌｅ
”３０１が関連付けられている。同様に、ｍｙｃｌａｓｓ３１０は、別の変数“
ｔｉｔｌｅ”３１１に対する異なる定義と関係付けられている。

【００４５】 図８は、それぞれの定義されたクラスについて宣言されている関数の関係を示
している。表３の中のコードは、ｂａｓｅｃｌａｓｓ３００およびｎｅｗｃｌａ
ｓｓ３２０に対して異なっている“ｍｙｆｕｎｃ”関数を定義しており、結果と
して、ｍｙｆｕｎｃ３０２がｂａｓｅｃｌａｓｓ３００と関係付けられ、そして
異なるｍｙｆｕｎｃ３２２関数がｎｅｗｃｌａｓｓ３２０と関係付けられている
。

【００４６】 図９は、継承図をそれぞれに関連付けられた変数および関数と統合化している
。ｂａｓｅｃｌａｓｓ３００には２つの変数、すなわち、ｔｉｔｌｅ３０１と、
関数のｍｙｆｕｎｃ３０２の両方を有している。また、クラスｍｙｃｌａｓｓ３
１０も１つの変数、すなわち、ｔｉｔｌｅ３１１を有している。それはｍｙｆｕ
ｎｃに対する定義を有していないので、それはｍｙｆｕｎｃ３０２のｂａｓｅｃ
ｌａｓｓ３００の定義からのｍｙｆｕｎｃ３１２に対する関数定義を継承する。
同様に、クラスｎｅｗｃｌａｓｓ３２０は、“ｔｉｔｌｅ”変数に対する値を有
しておらず、したがってｍｙｃｌａｓｓのタイトル定義３１１からのｔｉｔｌｅ
３２１に対するその定義を継承する。ｎｅｗｃｌａｓｓ３２０は関数ｍｙｆｕｎ
ｃ３２２に対するそれ自身の定義を有しており、これも継承図の中に反映されて
いる。

【００４７】 語い分析およびパージングのプロセスがターゲット・ドキュメントおよびその
コードの目的ロケーションのセクションの両方に対して繰り返される。図１０に
示されているように、ターゲット・ドキュメント“ｆｉｒｓｔ．ｔｘｔ”４００
は、ｂａｓｅｃｌａｓｓ３００のターゲット・ドキュメントであり、“ｓｅｃｏ
ｎｄ．ｔｘｔ”４１０はクラスｍｙｃｌａｓｓ３１０のターゲット・ドキュメン
トであり、そして“ｔｈｉｒｄ．ｔｘｔ”４２０は、クラスｎｅｗｃｌａｓｓ３
２０のターゲット・ドキュメントである。３つの各ターゲット・ドキュメントは
、適切なクラス関数“ｍｙｆｕｎｃ”に対する単独の関数呼出しから構成されて
いる。

【００４８】 すべてのソース・ファイルがトークン化され、既知の値へ構文解析されると、
その確立されたトークンおよび関係情報がコンパイラのページ・ジェネレータに
対してステップ２８６において渡される。

【００４９】 以前に図４で示されたように、コンパイラのページ・ジェネレータ２００は、
パーザ２０から転送されてきた関係およびトークンに基づいて各ターゲット・ド
キュメントを生成し、それぞれの適切な値で変数を置き換え、関数呼出しを評価
し、そして結果の情報を図１０に示されているページ・テーブルの中に代入する
。

【００５０】 ページ・ジェネレータのサブプロセスが図１４において詳細に示されている。
トークンの関係情報がコンパイラのページ・ジェネレータに対してステップ２８
６において渡される。各ページ・クラスに対して、その変数がそれぞれの定義で
ステップ２８８において置き換えられる。単純な実施形態においては、これはそ
の変数が現れる場所の各メモリ・テーブルの中への値の単なる代入であってよい
。すべてのページ・クラスに対する各関数呼出しが次にステップ２９０において
評価される。命名された各目的ロケーションの存在が検証され、ディレクトリな
どのそのロケーションが存在しなかった場合、それはこの時点でコンパイラによ
ってステップ２９２において生成される。ターゲット・ドキュメントに対応して
いる各ページが次に各目的ロケーションにおいてステップ２９４において書き込
まれる。最後に、その書込みがコンパイラによってステップ２９６において検証
される。

【００５１】 例えば、図１１に示されているように、“ｆｉｒｓｔ．ｔｘｔ”４００に対す
る出力が、そのページを生成する際に使用される関数および変数を定義する適切
なクラス、ｂａｓｅｃｌａｓｓ３００を通知することによって発生される。表３
は“ｔｉｔｌｅ”変数および“Ｔｈｉｓ ｉｓ ａ ｂａｓｅ ｃｌａｓｓ ｅ
ｘａｍｐｌｅ”を入力として使用して、“ｍｙｆｕｎｃ”に対する関数呼出しに
よって生成されるページとして“ｆｉｒｓｔ．ｔｘｔ”を定義する。“ｆｉｒｓ
ｔ．ｔｘｔ”は、クラスｂａｓｅｃｌａｓｓのテキストであるので、その“ｔｉ
ｔｌｅ”および“ｍｙｆｕｎｃ”に対する定義は、そのｂａｓｅｃｌａｓｓから
直接に取られる。その結果が表４に示されている。

【００５２】

【表４】 表４． “ｆｉｒｓｔ．ｔｘｔ”に対するコンパイルされた出力 図１２は、クラス“ｍｙｃｌａｓｓ”３１０のテキストである“ｓｅｃｏｎｄ
．ｔｘｔ”４１０に対するコンパイルを継続する。“ｔｉｔｌｅ”に対する定義
は、クラスｍｙｃｌａｓｓ３１０から直接に取られる。“ｍｙｆｕｎｃ”に対す
る定義は普通にクラスｍｙｃｌａｓｓ３１０から取られることになる。しかし、
“ｍｙｆｕｎｃ“は、ｍｙｃｌａｓｓ３１０に対しては定義されていないので、
ｍｙｃｌａｓｓの親のクラスに対するｍｙｆｕｎｃ関数の定義、ｂａｓｅｃｌａ
ｓｓ３００が使用される。“ｓｅｃｏｎｄ．ｔｘｔ”４１０に対してコンパイル
された結果が表５に示されている。

【００５３】

【表５】 表５． “ｓｅｃｏｎｄ．ｔｘｔ”に対するコンパイルされた出力 図１３は、クラス“ｎｅｗｃｌａｓｓ”３２０のテキストである“ｔｈｉｒｄ
．ｔｘｔ”４２０に対するコンパイルを継続する。“ｔｉｔｌｅ”および”ｍｙ
ｆｕｎｃ”に対する定義は普通にクラスｎｅｗｃｌａｓｓ３１０から直接に取ら
れる。しかし、その“ｔｉｔｌｅ”変数がｎｅｗｃｌａｓｓ３２０に対して定義
されていないので、ｎｅｗｃｌａｓｓの親のクラス、ｍｙｃｌａｓｓ３１０に対
する“ｔｉｔｌｅ”変数定義が使用される。“ｍｙｆｕｎｃ”がクラスｎｅｗｃ
ｌａｓｓ３１０に対して定義されているので、ｎｅｗｃｌａｓｓの“ｍｙｆｕｎ
ｃ”の定義が使用される。“ｔｈｉｒｄ．ｔｘｔ”４２０に対するコンパイル結
果が表６に示されている。

【００５４】

【表６】 表６ “ｔｈｉｒｄ．ｔｘｔ”に対するコンパイルされた出力 コンパイラが各ページをメモリの中に生成すると、各ページが各目的ロケーシ
ョンにおいてターゲット・ドキュメントとして書き込まれる。コンパイラはオプ
ションとして前に存在していない目的ロケーションを生成することができ、そし
てその書込みをその目的ロケーションにおいて検証することができる。その最も
好適な実施形態においては、ＴＯＣは両方のアクションを実行し、目的ロケーシ
ョンが生成されていない場合に警告メッセージをレポートし、あるいは、ターゲ
ット・ドキュメントの書込みにおいて問題が発生した場合にエラー・メッセージ
をレポートする。

【図面の簡単な説明】

【図１】従来のコンパイラ・プロセスの概要図（従来の技術）。

【図２】従来のコンパイラの基本構成要素を示す図（従来の技術）。

【図３】テキスト・オブジェクト・コンパイラ（ＴＯＣ）プロセスの概要を
示す図。

【図４】テキスト・オブジェクト・コンパイラの基本構成要素を示す図。

【図５】テキスト・オブジェクト・コンパイラによって使用される語い分析
およびパージングのサブプロセスのフローチャート。

【図６】表３にリストされているテキスト・オブジェクト言語のソース・フ
ァイルのクラスの継承図。

【図７】クラス変数とクラスとの関係を示す継承図。

【図８】クラス関数とクラスとの関係を示す継承図。

【図９】それぞれの関数および変数を伴うクラスを統合化している継承図。

【図１０】定義されたページとクラスとの関係を示す継承図。

【図１１】ターゲット・ドキュメント“ｆｉｒｓｔ．ｔｘｔ”を生成するた
めに使用されるｂａｓｅｃｌａｓｓの情報を示す図。

【図１２】ターゲット・ドキュメント“ｓｅｃｏｎｄ．ｔｘｔ”を生成する
ために使用されるｂａｓｅｃｌａｓｓおよびｍｙｃｌａｓｓの情報を示す図。

【図１３】ターゲット・ドキュメント“ｔｈｉｒｄ．ｔｘｔ”を生成するた
めに使用されるｂａｓｅｃｌａｓｓ、ｍｙｃｌａｓｓ、およびｎｅｗｃｌａｓｓ
の情報を示す図。

【図１４】ページ生成のサブクラスの詳細を示すフローチャート。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｒ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ， ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，Ｋ Ｚ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ， ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，Ｓ Ｌ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ

Claims (17)

【特許請求の範囲】
1. 【請求項１】 コンピュータであって、 ａ．ソース入力をトークン化し、前記ソース入力の正規表現を表しているトー
   クンを作り出す語いアナライザと、 ｂ．前記トークン間の関係を決定するパーザと、 ｃ．前記トークンおよび前記トークン間の前記関係を評価し、非実行可能出力
   を発生するページ・ジェネレータとを含むコンピュータ。
2. 【請求項２】 請求項１に記載のコンピュータにおいて、前記ページ・ジェ
   ネレータが前記出力をファイルとして書き込むコンピュータ。
3. 【請求項３】 請求項２に記載のコンピュータにおいて、前記ページ・ジェ
   ネレータが前記ファイルを前記ソース入力の中で指定された目的ロケーションに
   おいて書き込むコンピュータ。
4. 【請求項４】 請求項１に記載のコンピュータにおいて、前記正規表現が変
   数を含むコンピュータ。
5. 【請求項５】 請求項１に記載のコンピュータにおいて、前記正規表現が関
   数を含むコンピュータ。
6. 【請求項６】 請求項１に記載のコンピュータにおいて、前記正規表現がク
   ラスを含むコンピュータ。
7. 【請求項７】 請求項１に記載のコンピュータにおいて、前記正規表現が変
   数、関数、およびクラスを含むコンピュータ。
8. 【請求項８】 コンピュータ・システムを動作させてテキスト・オブジェク
   ト言語をコンパイルするための方法であって、 ソース入力を語いに分析し、前記ソース入力の正規表現を表しているトークン
   を発生するステップと、 前記トークンを構文解析して前記トークン間の関係を決定するステップと、 前記トークンおよび前記トークン間の前記関係を評価して非実行可能出力を発
   生するステップとを含む方法。
9. 【請求項９】 請求項８に記載の方法において、 前記非実行可能出力をファイルに書き込むステップをさらに含む方法。
10. 【請求項１０】 請求項９に記載の方法において、前記ファイルが前記ソー
    ス・ファイルの中で指定されている目的ロケーションにおいて書き込まれる方法
    。
11. 【請求項１１】 請求項８に記載の方法において、前記正規表現が変数を含
    む方法。
12. 【請求項１２】 請求項８に記載の方法において、前記正規表現が関数を含
    む方法。
13. 【請求項１３】 請求項８に記載の方法において、前記正規表現がクラスを
    含む方法。
14. 【請求項１４】 請求項８に記載の方法において、前記正規表現が変数、関
    数、およびクラスを含む方法。
15. 【請求項１５】 コンピュータ・システムを動作させてテキスト・オブジェ
    クト言語をコンパイルする方法であって、 変数、関数、およびページの定義を含む、テキスト・オブジェクト言語の正規
    表現を含むソース入力を読み取るステップと、 前記ソース入力を語いに分析して、ｐａｇｅトークンを含む前記正規表現のト
    ークンを発生するステップと、 前記トークンを構文解析して前記トークン間の関係を決定するステップと、 前記トークンおよびそれぞれの関係の表現をコンピュータ・メモリの中で構築
    するステップと、 変数および関数を表す前記トークンを評価してそれぞれの評価された値を決定
    するステップと、 前記変数トークンおよび前記関数トークンのコンピュータ・メモリ表現をそれ
    ぞれの評価された値で置き換えるステップと、 前記ｐａｇｅトークンの前記コンピュータ・メモリ表現に基づいて非実行可能
    ファイルを書き込むステップとを含む方法。
16. 【請求項１６】 請求項１５に記載の方法において、前記非実行可能ファイ
    ルが前記ソース入力によって指定されている目的ロケーションにおいて書き込ま
    れる方法。
17. 【請求項１７】 請求項１５に記載の方法において、前記正規表現がクラス
    を含む方法。