さて, ここで1つ問題がある.
先にもあげたように, KLICシステムでは, 複数のKL1モジュールを 1つづつ別々にコンパイルすることができる. これらのモジュールの間では「記号」がやりとりされることは 当然考えられる. しかしながら, 前章で説明したように, 処理の効率を良くするため, 「記号」は, 内部では番号として扱われており, しかもコンパイルを行なう際に変換してしまう. モジュールの間で「記号」は受け渡されるので, 異なったモジュールであっても同じ「記号」は同じ番号として 変換される必要が生じる. 「``foo''という記号はこのモジュールでは104番だけど, あのモジュールでは253番で, それはそのモジュールの``bar''という記号の 番号と同じになった」などということが起きてもらっては困るのである.
この問題の解決のために用いられているのが, klic.db
というファイルである.
このファイルの中には,
「どの記号はどの番号に変換されたか」が記録されている.
KL1コンパイラは記号を見付けるたびに, このファイルにすでに登録されているか
どうか調べ, すでに登録されていれば, その番号に変換するようにしている.
登録されていなければ (他に, まだ, コンパイルを行なっていない,
同じ記号を使っているKL1プログラムがあるかも知れないので)
そのファイルに「この記号は何番に変換したよ」ということを残しておく.
つまり, このファイルを介して, 複数のKL1コンパイラが記号
番号の変換規則をやりとりしているわけである.
ファイルklic.dbは, 「KLICデータベース管理システム」
(klicdb) というプログラムで管理されている.
このプログラムにより
atom.h, funct.hなるファイルも生成され
KLICコンパイラが生成したCプログラム内に取り込まれることにより
記号
番号の変換がCコンパイル時に行なわれる.
このklic.dbに書かれている情報は,
KLICシステムで作られたプログラムが実行される時も
必要であるため, Cプログラムに変換され, コンパイル/リンクされる.
これが, atom.c, funct.c, predicates.cといったファ
イルである.
従って, KLICシステムを使って, 複数のプログラムを作成してコンパイル/
プログラム修正を繰り返している時に, ここで挙げたファイルが無くなってしまうと,
それ以降の処理はおかしくなることがある. 以下であげるファイルは
作った覚えがないからといって, 消してしまってはならない.
もし, 消してしまった場合は, -R という強制再コンパイルオプションで
.kl1プログラムをコンパイルし直すようにすれば,
これらのファイルはまた生成される.
この記号のメンテナンス関連の処理も含めたklicシステム全体の ファイル/処理の流れを図1.5に示す.
