![]() ![]() Our goal is to support both Prolog systems in a single codebase – we are not planning to drop support for SICStus Prolog, but we also do not want to maintain separate branches for the two systems. Reference Wielemaker, Schrijvers, Triska and Lager2012). Recently, we have begun refactoring the ProB codebase to make it compatible with more than just SICStus Prolog, with a specific focus on supporting SWI-Prolog (Wielemaker et al. As a result, the ProB codebase makes heavy use of SICStus-specific features and libraries, and compatibility with other Prolog systems was generally not considered in its past development. It has been in continuous development since the early 2000s, based entirely on the SICStus Prolog system (Carlsson and Mildner Reference Carlsson and Mildner2012). The application in question, ProB, is an animator, constraint solver, and model checker for formal specifications of safety-critical systems. Developers may also make the conscious choice to only support a single system, in order to reduce development effort or to make full use of a specific system’s unique features.Īs a case study, this paper examines the process of refactoring a large nonportable Prolog application to make it compatible with other Prolog systems. As Prolog applications are often only tested on the Prolog system for which they were originally developed, it is easy to accidentally rely on features and behavior not supported by other systems. Most nontrivial Prolog code thus requires non-ISO features provided by individual systems. The ISO standard core language alone is insufficient for many programs, as it does not provide important features like a module system, constraint programming, or even simple standard libraries like library(lists). This situation complicates writing Prolog code that can be run on multiple different Prolog systems. Some features are entirely specific to one system and not supported by other systems at all (Körner et al. ![]() For many other features, no clear standard has emerged though, with different systems often supporting the same feature with different interfaces. Some of these nonstandard features have established themselves as de facto standards that are widely and consistently implemented across many modern Prolog systems. Furthermore, as this standard only specifies the core of the Prolog language, it does not cover the libraries and advanced language features of modern full-featured Prolog systems. To establish a common basic definition of Prolog, the core of the language was formalized in an ISO standard (ISO/IEC 13211-1:1995 1995), which is followed by the vast majority of Prolog implementations nowadays – although some intentionally deviate from the standard in small or large ways. ![]() Each of these implementations supports a different feature set than all others, often introducing new extensions to the language and libraries while changing or removing other features. New implementations of Prolog were (and still are) created regularly, either derived from other existing implementations or developed completely from scratch. ![]() We also describe notable compatibility issues and other differences that we encountered in the process, and how we were able to deal with them with few major code changes.įor most of its existence, the Prolog programming language has been continuously developed and extended by different groups, often in parallel and somewhat independently from one another. This required a multitude of adjustments, ranging from extending the SICStus emulation in SWI-Prolog on to better modularizing the monolithic ProB codebase. The article describes how we managed to refactor the codebase of ProB to also support SWI-Prolog, with the goal of verifying ProB’s results using two independent toolchains. We examine one such Prolog application: ProB, which has been developed for over 20 years in SICStus Prolog. Most Prolog applications thus have to rely on nonstandard features, often making them dependent on one particular Prolog implementation and incompatible with others. Indeed, implementations sometimes deviate from the ISO standard and the standard itself fails to cover many features that are essential in practice. Even though the core of the Prolog programming language has been standardized by ISO since 1995, it remains difficult to write complex Prolog programs that can run unmodified on multiple Prolog implementations. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |