MINERVA superseeded IF/Prolog.
Please see
http://www.ifcomputer.co.jp/MINERVA
for details.
We discontinued to sell IF/Prolog Dec 31. 2003.
For current customers, we continue to provide
professional support for IF/Prolog until Dec 31, 2008.
ソフトウェア開発では、開発が進むにつれ、プログラムが大きくなり、1つのコードの塊として管理できなくなります。Prologプログラムも例外ではありません。 この問題を解決するためには、当然プログラムを複数の管理可能な程度の述語群に分けなければなりません。この際、「一緒においておくべき」述語、すなわち、関連した処理を行なうとか、互いに依存するとか、同じデータを使用するなどといった性質を持つ述語をまとめるようにするわけですが、ソフトウェア工学ではこのような関連するコードの塊をモジュールと呼びます。モジュール化の方法は、プログラミング言語により異なります。
Prologにおいては、モジュール化の最初の重要なステップは、修正・コンサルト・リコンサルトが別々に行えるように、ソースコードをいくつかのファイルに分けることです。(通常、プログラマは、複数のモジュールのコンサルトをする指令しか含まないトップレベルのソースファイルを作り、このトップレベルのファイルをコンサルトするだけでプログラム全体をロードすることができるようにします。) この方法は、別々に作ったファイルをコンサルトすることさえできればよいので、標準的なPrologシステムのほとんどで使用することができます。
多くの場合、この方法はわかりやすくて良い方法なのですが、複数のプログラマが大規模なソフトウェアを開発している場合には問題が生じます。というのは、ある特定のモジュールのためのコードを書いているプログラマがたまたま使用した述語・関数子・アトム・グローバル変数などの名前が、他のプログラマが別のモジュールで使用している名前と衝突してしまうかも知れないからです。この結果は通常プログラムの思わぬ振舞いとなって現れるので解決が難しく、非常に大きな問題となり得ます。例えば、Prologでは、他の場所で使われている述語の名前を別なところで定義し、それを含むファイルをリコンサルトすれば、それ以前のその述語の定義は抹消されてしまします。名前の付け方における問題は、すべてのプログラミング言語に共通して存在します。しかし、データベースがグローバル情報の唯一の格納場所である標準的なPrologでは、問題はより深刻です。Prologでは、コードとデータの差がなく、どちらも同一の名前空間で扱われます。この特徴は、Prologのフレキシビリティの源泉となる重要な利点であり、名前の衝突の問題をどう解決するにしても、捨てるわけにはいきません。
|