Portability of Prolog programs: theory and case-studies

(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.

💡 Research Summary

The paper tackles the long‑standing issue of Prolog program portability, which has often been cited as a barrier to wider adoption of the language. Although the ISO 13211‑1 standard has defined the core syntax and semantics since 1995, many Prolog implementations have diverged by adding proprietary built‑ins, differing module systems, and varying I/O behaviours. This fragmentation is especially pronounced among the Edinburgh/Quintus family of systems (SICStus, Ciao, YAP, SWI‑Prolog, etc.).

Starting in 2007, developers of YAP and SWI‑Prolog collaborated to create a compatibility framework whose primary goal is run‑time compatibility: the same source file should execute unchanged on both engines and produce identical results. The framework is built around four pillars: (1) a unified module declaration and export mechanism, (2) a set of wrapper predicates that expose a common API for standard libraries such as lists, apply, and format, (3) systematic mapping of non‑standard built‑ins (e.g., thread creation, non‑backtrackable assignment) to a shared signature, and (4) conditional compilation directives (:- if/1 … :- endif.) that allow implementation‑specific code to be isolated cleanly.

Implementation details are concentrated in a single file, compatibility.pl. At load time the file detects the current dialect via current_prolog_flag(dialect,…) and activates the appropriate macro definitions and wrapper predicates. A comprehensive test suite, built with plunit, contains over 200 unit tests and 30 integration scenarios, and is run automatically on a continuous‑integration server for both YAP and SWI‑Prolog.

The authors evaluate the framework through four real‑world case studies: (a) a lightweight HTTP server framework, (b) database access layers using ODBC and PostgreSQL, (c) a natural‑language‑processing pipeline that relies on several external libraries, and (d) a collection of university teaching examples. In each case the majority of the code ran unchanged on both systems. The only obstacles encountered were (i) C‑foreign‑interface modules that required recompilation, (ii) file‑path conventions (Windows vs. Unix), and (iii) slight differences in thread and process APIs. All of these were resolved either by the compatibility wrappers or by adding small adapter modules.

Beyond the technical results, the paper argues that improved portability has a multiplier effect on the Prolog ecosystem. A stable, cross‑engine development environment reduces the learning curve for newcomers, encourages sharing of open‑source libraries, and lowers the risk for industry adopters who can now rely on a single code base regardless of the underlying engine.

The authors also discuss future work. While the current framework covers the major Edinburgh/Quintus derivatives, extending it to other Prolog systems such as B‑Prolog or XSB would broaden its impact. Moreover, as the ISO standard evolves to include modern features like module‑level type declarations and high‑performance parallel execution, the compatibility layer will need to be updated accordingly. The paper proposes the creation of a community‑maintained “compatibility registry” that documents non‑standard extensions and provides automated mapping tools, thereby keeping the maintenance burden low.

In conclusion, the YAP–SWI‑Prolog compatibility framework demonstrates that, for the Edinburgh/Quintus family, portable Prolog programming is now a realistic goal. The extensive empirical evaluation shows that most real‑world applications can be run on both engines with little or no modification, and the remaining incompatibilities are well‑understood and manageable. This progress suggests that portability is no longer a decisive obstacle, and that continued standardization and framework maintenance will further solidify Prolog’s position in both academic research and commercial applications.