[論文レビュー] Portability of Prolog programs: theory and case-studies

Jan Wielemaker, Vı́tor Santos Costa|arXiv (Cornell University)|Sep 20, 2010

Software Testing and Debugging Techniques参考文献 10被引用数 3

ひとこと要約

この論文は、SWI-Prolog、YAP、SICStus、Ciao の主要な ISO準拠 Prolog システム間で、条件付きコンパイルと抽象化レイヤーを用いて、Prolog プログラムの高い移植性を実現する実用的なフレームワークを提示している。主な貢献は、Alpino 自然言語処理系のような実世界のアプリケーションが、最小限の条件付きコードで完全に移植可能であることを示したことである。これにより、大規模な再実装なしにクロスプラットフォーム互換性が達成可能である。

ABSTRACT

(Non-)portability of Prolog programs is widely considered as an important factor in the lack of acceptance of the language. Since 1995, the core of the language is covered by the ISO standard 13211-1. Since 2007, YAP and SWI-Prolog have established a basic compatibility framework. This article describes and evaluates this framework. The aim of the framework is running the same code on both systems rather than migrating an application. We show that today, the portability within the family of Edinburgh/Quintus derived Prolog implementations is good enough to allow for maintaining portable real-world applications.

研究の動機と目的

• 文法、ライブラリ、システムインターフェースの方言特有の差異による、長年の Prolog プログラムの非移植性問題に対処すること。
• 主にエディンバラ/クインタス継承の Prolog 実装間でのベンダーロックインを低減し、相互運用性を向上させること、特にそれらの実装において。
• 理論的ではなく実際の事例を通じて、高水準の移植性が実現可能であることを示すこと。
• 項のシリアル化、スレーディング、Unicode、外部言語インターフェースなどのコア機能における主な不整合を特定・解決すること。
• システムベンダーとの協働と一般的に使用される予約語やフラグの標準化を通じて、継続的な移植性向上のための持続可能なフレームワークを提唱すること。

提案手法

• Prolog の if/1 指令を用いた条件付きコンパイルにより、ターゲット Prolog システムに応じてコードを条件的に含める。これにより、1つのソースベース内でプラットフォーム固有の実装が可能になる。
• Prolog の自己反映機能（例：動的予約語の操作）を活用し、GNU autoconf のような外部構成ツールに代わって、実行時におけるシステム機能の自己診断を可能にする。
• GUI インターフェース（tcl/tk）、ファイル I/O、項シリアル化などの移植性のない機能に対して、必要に応じてエミュレーションまたは再実装を行うことで、移植可能な抽象化を実装する。
• ファイル名解決、メッセージ配信、Prolog フラグなどの重要なシステム機能に対して、共通インターフェースレイヤーを構築し、アプリケーション論理と実装固有の詳細を分離する。
• SWI-Prolog などのコアシステムに対して最小限の変更を加え、他のシステムとの整合性を高める。特に write_term/3 の出力フォーマットや UTF-8 対応の分野で。
• Alpino のような実世界のアプリケーションにこのフレームワークを適用し、19,000 行を超えるコードベースにおいて、SWI-Prolog と SICStus Prolog の両方をサポートするために、たった 59 箇所の条件付きコンパイルポイントを変更した。

実験結果

リサーチクエスチョン

• RQ1 主要な ISO準拠 Prolog システム間で、大規模な再設計なしに、どの程度 Prolog プログラムを移植可能にできるか？
• RQ2 Prolog の if/1 指令を用いた条件付きコンパイルは、ライブラリやシステムインターフェースのシステム固有の差異を管理するためにどの程度効果的か？
• RQ3 Prolog の移植性における主な技術的障壁は何か。それらはどのように体系的に解決できるか？
• RQ4 Alpino のような実世界の複雑なアプリケーションが、最小限の変更と完全な機能同等性を保ちながら、複数の Prolog システムに移植可能か？
• RQ5 ベンダーとの協働と標準化は、実装間の相互運用性向上にどのような役割を果たすか？

主な発見

• このフレームワークにより、Alpino のような複雑な実世界の Prolog アプリケーションが、コードベース全体でたった 59 個の条件付きコンパイルディレクティブで、SWI-Prolog と SICStus Prolog 間で完全に移植可能になった。
• Alpino アプリケーションは、C コードに一切変更を加えず、Prolog コードの変更も最小限に抑え、条件付きコンパイルと抽象化レイヤーに依存して、両方のシステムで正常に動作するように移植された。
• SWI-Prolog は UTF-8 対応と write_term/3 の正しい出力フォーマットをサポートするよう拡張され、SICStus との出力が一致するようになり、深刻な不整合が解消された。
• tcl/tk インターフェースは、Ciao のインターフェースを模倣する 17 ファイルのエミュレーションを置き換える形で、移植可能なライブラリとして再実装され、複雑さが軽減され、保守性が向上した。
• SWI-Prolog のメッセージキューのパフォーマンスは、pthread-win32 からネイティブ Windows API に書き直したことで顕著に向上し、100倍のパフォーマンスペナルティが解消された。
• 著者らは、4つの主要な Prolog システム間の移植性が、1990年代の Unix 上の C 言語の移植性と同等であると結論づけ、クロスプラットフォーム開発のための成熟した安定基盤が整ったと述べている。