Conference PaperPDF Available

A portable Prolog compiler

Authors:
... Following David H.D. Warren's first Prolog compiler, described in 2.4.3, there were a number of other compiled systems up until 1983, including Prolog-X (Bowen et al., 1983) and later NIP, the "New Implementation of Prolog" (for details, cf. the survey by Van Roy (1994)). ...
... At its very core, SWI-Prolog is based on an extended version of the ZIP virtual machine by Bowen et al. (1983), that is, a minimal virtual machine for Prolog implementing a simple language consisting of only seven instructions. SWI-Prolog-specific extensions aim at improving performance in several ways: ad-hoc instructions are introduced to support unification, predicate invocation, some frequently used built-in predicates, arithmetic, control flow, and negation-as-failure. ...
Article
Both logic programming in general and Prolog in particular have a long and fascinating history, intermingled with that of many disciplines they inherited from or catalyzed. A large body of research has been gathered over the last 50 years, supported by many Prolog implementations. Many implementations are still actively developed, while new ones keep appearing. Often, the features added by different systems were motivated by the interdisciplinary needs of programmers and implementors, yielding systems that, while sharing the “classic” core language, in particular, the main aspects of the ISO-Prolog standard, also depart from each other in other aspects. This obviously poses challenges for code portability. The field has also inspired many related, but quite different languages that have created their own communities. This article aims at integrating and applying the main lessons learned in the process of evolution of Prolog. It is structured into three major parts. First, we overview the evolution of Prolog systems and the community approximately up to the ISO standard, considering both the main historic developments and the motivations behind several Prolog implementations, as well as other logic programming languages influenced by Prolog. Then, we discuss the Prolog implementations that are most active after the appearance of the standard: their visions, goals, commonalities, and incompatibilities. Finally, we perform a SWOT analysis in order to better identify the potential of Prolog and propose future directions along with which Prolog might continue to add useful features, interfaces, libraries, and tools, while at the same time improving compatibility between implementations.
... Following David H.D. Warren's first Prolog compiler, described in 2.4.3, there were a number of other compiled systems up until 1983, including Prolog-X (Bowen et al., 1983) and later NIP, the "New Implementation of Prolog" (for details, cf. the survey by Van Roy (1994)). ...
... At its very core, SWI-Prolog is based on an extended version of the ZIP virtual machine by Bowen et al. (1983), that is, a minimal virtual machine for Prolog leveraging upon a simple language consisting of only seven instructions. SWI-Prolog-specific extensions aim at improving performance in several ways: ad-hoc instructions are introduced to support unification, predicate invocation, some frequently used built-in predicates, arithmetic, control flow, and negation-asfailure. ...
Preprint
(Under consideration for publication in Theory and Practice of Logic Programming) Both logic programming in general, and Prolog in particular, have a long and fascinating history, inter-mingled with that of many disciplines they inherited from or catalyzed. A large body of research has been gathered over the last 50 years, supported by many Prolog implementations. Many implementations are still actively developed, while new ones keep appearing. Often, the features added by different systems were motivated by the interdisciplinary needs of programmers and implementors, yielding systems that, while sharing the "classic" core language, and, in particular, the main aspects of the ISO-Prolog standard, also depart from each other in other aspects. This obviously poses challenges for code portability. The field has also inspired many related, but quite different languages that have created their own communities. This article aims at integrating and applying the main lessons learned in the process of evolution of Prolog. It is structured into three major parts. Firstly, we overview the evolution of Prolog systems and the community approximately up to the ISO standard, considering both the main historic developments and the motivations behind several Prolog implementations, as well as other logic programming languages influenced by Prolog. Then, we discuss the Prolog implementations that are most active after the appearance of the standard: their visions, goals, commonalities, and incompatibilities. Finally, we perform a SWOT analysis in order to better identify the potential of Prolog, and propose future directions along which Prolog might continue to add useful features, interfaces, libraries, and tools, while at the same time improving compatibility between implementations.
... This requires some assumptions with respect to the format in which the logic programming variables are stored in memory and the types of variables to be distinguished. Besides the logic program constructs, such as variable, constant, structure, and list, AIK-O also allows one to distinguish cases which have proven to be useful (see [7,13,14]) for the implementation of Prolog compilers, such as local variable, global variable, permanent variable, temporary variable, etc. In addition, Read-only variables are supported as required with certain parallel logic programming languages such as Concurrent Prolog and Parlog (see below). ...
... SWI-Prolog's kernel is loosely based on the ZIP [1, 3] virtual machine. The Prolog engine is not designed for speed, but has all commonly seen optimisations to avoid memory exhaustion in 24*7 services: last call optimisation, garbage collection and atom garbage collection. ...
Article
Full-text available
Development of the SWI-Prolog environment has started in 1985. Its developments was started in the context of interactive application development. More recently the development is guided by Semantic Web application develop-ment and contributions from the world wide community. In this article we will briefly introduce the SWI-Prolog community, touch the many features and outline our future plans. The primary aim of the Logic Programming Systems series is to provide an overview of system features. We deliberately concentrate more on the context in which the development of SWI-Prolog started, how this is currently shaped and what our plans are. A big table is more suitable for a product comparison. An outline of the community is hopefully more pleasant to read and provides more stable information about the system. 1 The SWI-Prolog history and community We started SWI-Prolog in a EU project (KADS) where we built a workbench for Knowl-edge Engineering. Several partners had a background in AI and where used to Prolog. These were the days where graphical user interfaces just started to emerge, in our case SunView on SUN workstations. Anjo Anjewierden created an object-oriented connec-tion between Prolog and SunView, called PCE [7]. The initial system used Quintus Pro-log which, in those days, 1 could call C, but could not be called from C. This limitation severely handicapped PCE. In the meanwhile SWI-Prolog was created as a toy Prolog system, but designed with a bi-directional C interface from the start. Just for play, we connected it to PCE and added enough built-ins to run our workbench-under-development. Enhanced func-tionality of PCE resulting from the bi-directional interface, a very fast compiler and the make/0 feature to recompile modified source files quickly moved the whole consortium to use this new Prolog. As we had no concrete plans with it, we put it the source on the anonymous ftp server under a non-commercial-use license. Somehow the sources were picked up, as it turned out mostly by Universities as the default system for teaching Prolog classes. Most likely because the system was simple, small, installed easily on most Unix systems in common use and it could be used 1 Quintus, as most other todays Prolog systems offer a good bidirectional C interface.
... In WAM-based systems with registers, the list resides in a register that is overwritten in each recursion. On virtual machines such as the ZIP [8, 9] and ATOAM [10] that pass arguments over the stack, last-call optimization overwrites the arguments, making the head inaccessible. We will now go systematically through requirements to deal with infinite (lazy) datastructures. ...
Article
Full-text available
In this paper we present a series of tiny programs that verify that a Prolog heap garbage collector can find specific forms of garbage. Only 2 out of our tested 7 Prolog systems pass all tests. Comparing memory usage on realistic programs dealing with finite datastructures using both poor and precise garbage collection shows only a small dif-ference, providing a plausible explanation why many Prolog implemen-tors did not pay much attention to this issue. Attributed variables allow for creating infinite lazy datastructures. We prove that such datastruc-tures have great practical value and their introduction requires 'precise' garbage collection. The Prolog community knows about three techniques to reach at precise garbage collection. We summarise these techniques and provide more details on scanning virtual machine instructions to infer reachability in a case study.
Article
Delimited continuations are a famous control primitive that originates in the functional programming world. It allows the programmer to suspend and capture the remaining part of a computation in order to resume it later. We put a new Prolog-compatible face on this primitive and specify its semantics by means of a meta-interpreter. Moreover, we establish the power of delimited continuations in Prolog with several example definitions of high-level language features. Finally, we show how to easily and effectively add delimited continuations support to the WAM.
Article
In this paper we study the compilation of Prolog by making visible hidden operations (especially unification), and then optimizing them using well-known partial evaluation techniques. Inspection of straightforward partially evaluated unification algorithms gives an idea how to design special abstract machine instructions which later form the target language of our compilation. We handle typical compiler problems like representation of terms explicitly. This work gives a logical reconstruction of abstract Prolog machine code, and represents an approach of constructing a correct compiler from Prolog to such a code. As an example, we are explaining the unification principles of Warren’s New Prolog Engine within our framework.
ResearchGate has not been able to resolve any references for this publication.