[論文レビュー] An Architecture for Making Object-Oriented Systems Available from Prolog

Jan Wielemaker, Anjo Anjewierden|ArXiv.org|Jul 12, 2002

Logic, programming, and type systems参考文献 1被引用数 16

ひとこと要約

本論文は、特にGUIライブラリを含む外部のオブジェクト指向（OO）システムを、Prolog内での1等級のエンティティとしてオブジェクトとメソッドを公開することで、Prologへのシームレスな統合を可能にする汎用アーキテクチャを提示する。このアプローチは、軽量で型安全なインターフェースを用い、Prologの項をOOオブジェクトにマッピングし、境界を越えたメソッド呼び出しを可能にするとともに、完全なデバッグと段階的開発をサポートする。低遅延通信（1–5.2 μs/コール）を達成しながら、アプリケーション論理とGUIコンポーネントの両方を純粋なPrologで開発可能となる。

ABSTRACT

It is next to impossible to develop real-life applications in just pure Prolog. With XPCE we realised a mechanism for integrating Prolog with an external object-oriented system that turns this OO system into a natural extension to Prolog. We describe the design and how it can be applied to other external OO systems.

研究の動機と目的

• Prologは効率的なGUI開発のためのネイティブなサポートを欠いているため、強力な外部のオブジェクト指向GUIシステムをPrologに統合する課題に対処すること。
• Prologと外部GUIコードの間で手動でメンテナンスされる別個のブリッジを排除し、PrologからOOシステムへの直接的かつ透明なアクセスを可能にすること。
• Prologプログラマーがアプリケーション論理とGUIコンポーネントの両方を、同じ言語とツールを用いて完全にPrologで開発できること。
• 実行時におけるクラスとメソッドの動的生成を可能にし、Prolog内から直接OOシステムを迅速にプロトタイピングし、拡張できること。
• 外部コードやイベント駆動型GUIインタラクションが存在する中でも、Prologの完全なデバッグと段階的開発の能力を維持すること。

提案手法

• アーキテクチャは4つのコアとなるProlog述語を定義する：`new/2`（オブジェクト作成）、`send/3`（メソッド呼び出し）、`get/3`（属性アクセス）、`is_a/2`（型チェック）、これらはすべて下位のOOシステムを抽象化する。
• Prologのデータ型（原子、整数、複合項）を対象となるOOシステム（例：XPCE）の型にマッピングし、自動変換と型安全性を実現する。
• インターフェースはCを共通の言語ブリッジとして使用し、C互換の関数ポインタを用いて外部のOOシステムのメソッドを呼び出すことで、パフォーマンスとポータビリティを確保する。
• 動的メソッドディスpatchとランタイムでのクラス生成をサポートし、再コンパイルなしにProlog内で新しいクラスとメソッドを定義・使用可能にする。
• Prologのネイティブデバッガと統合し、外部/Prolog境界を越えたスタックコンテキストを保持し、Prologおよび外部コードの両方でブレークポイントを設定可能にする。
• すべてのアプリケーション論理がProlog上で実行されることを保証し、開発ライフサイクル全体でPrologの段階的コンパイルおよびデバッグツールが利用可能になる。

実験結果

リサーチクエスチョン

• RQ1 Prologに低レベルのCバインディングや別個のGUIコードを必要とせずに、外部のオブジェクト指向システム（例：GUIライブラリ）をネイティブかつ透明にアクセスできるようにするにはどうすればよいか？
• RQ2 PrologからOOシステムへのインターフェースによって生じるパフォーマンスのオーバーヘッドはどの程度か。また、インタラクティブなGUIアプリケーションに適した低オーバーヘッドを達成できるか？
• RQ3 Prologコードと外部のイベント駆動型OOシステムを混合させた場合でも、完全なデバッグと段階的開発が維持可能か？
• RQ4 継承、動的メソッドディスpatch、ランタイムでのクラス生成といったオブジェクト指向プログラミングの概念が、どの程度Prolog内から公開され、利用可能になるか？
• RQ5 アプリケーション論理とGUIコンポーネントが両方とも完全にPrologで書かれ、デバッグ可能となる統合開発環境をどのように実現できるか？

主な発見

• PrologからOOシステムへのインターフェースは低遅延のメソッド呼び出しを達成しており、AMD 1600+プロセッサ上で1コールあたり1.0～5.2マイクロ秒の実行時間が測定された。
• Cで定義された組み込みメソッド（例：`normalise`）を呼び出す際のオーバーヘッドはたったの1.0 μsであり、インタラクティブなGUIに適した高い効率性を示している。
• Prologおよび外部コードの両方の完全なデバッグが可能であり、SWI-PrologのデバッガはProlog-外部境界を越えたスタックトレースを交互に表示できる。
• Prologおよび外部コードの両方でブレークポイントを設定可能であり、実行中に突然発生するイベント駆動型呼び出し（例：マウスドラッグ）に対してもデバッガが対応可能である。
• 新しいクラスとメソッドは実行時にProlog内で動的に生成可能であり、再コンパイルやソースファイルの生成なしに外部のOOシステムをシームレスに拡張可能である。
• このアーキテクチャにより、GUIとアプリケーション論理の両方が完全にPrologで統合的に開発可能となり、複雑なインターフェース同期を必要とする別個のGUIプログラムとPrologプログラムの必要性が排除された。