It has now been 40 years since the birth of the Prolog language and of its first implementation by A. Colmerauer and P. Roussel. Since then, a large number of Prolog systems have been implemented. While the core of the Prolog language has not changed much in these 40 years, Prolog systems have undergone an extraordinary evolution that stems from two main sources. One is the trend to extend Prolog to incorporate ideas from other language paradigms that have proved useful in real-world applications. This includes concurrency, parallelism, higher order predicates, object-oriented programming, Web interfaces, processing of large amounts of data, and flexible developer tools that enhance reliability and robustness through assertions. A second source of change is the exploration of ideas for which Prolog systems are uniquely suitable and that have led to the creation of new programming paradigms. This includes tabling, constraint logic programming, answer set programming, and probabilistic logic programming.

Yet Another Prolog (YAP) is a Prolog system originally developed in the mid-eighties and that has been under almost constant development since then. This paper presents the general structure and design of the YAP system, focusing on three important contributions to the Logic Programming community. First, it describes the main techniques used in YAP to achieve an efficient Prolog engine. Second, most Logic Programming systems have a rather limited indexing algorithm. YAP contributes to this area by providing a dynamic indexing mechanism, or just-in-time indexer. Third, a important contribution of the YAP system has been the integration of both or-parallelism and tabling in a single Logic Programming system.

SICStus Prolog has evolved for nearly 25 years. This is an appropriate point in time for revisiting the main language and design decisions, and try to distill some lessons. SICStus Prolog was conceived in a context of multiple, conflicting Prolog dialect camps and a fledgling standardization effort. We reflect on the impact of this effort and role model implementations on our development. After summarizing the development history, we give a guided tour of the system anatomy, exposing some designs that were not published before. We give an overview of our new interactive development environment, and describe a sample of key applications. Finally, we try to identify key good and not so good design decisions.

SWI-Prolog is neither a commercial Prolog system nor a purely academic enterprise, but increasingly a community project. The core system has been shaped to its current form while being used as a tool for building research prototypes, primarily for knowledge-intensive and interactive systems. Community contributions have added several interfaces and the constraint (CLP) libraries. Commercial involvement has created the initial garbage collector, added several interfaces and two development tools: PlDoc (a literate programming documentation system) and PlUnit (a unit testing environment).

In this article, we present SWI-Prolog as an integrating tool, supporting a wide range of ideas developed in the Prolog community and acting as glue between foreign resources. This article itself is the glue between technical articles on SWI-Prolog, providing context and experience in applying them over a longer period.

We describe the BinProlog system's compilation technology, runtime system and its extensions supporting first-class Logic Engines while providing a short history of its development, details of some of its newer re-implementations as well as an overview of the most important architectural choices involved in their design. With focus on its differences with conventional Warren Abstract Machine (WAM) implementations, we explain key details of BinProlog's compilation technique, which replaces the WAM with a simplified continuation passing runtime system (the “BinWAM”), based on a mapping of full Prolog to binary logic programs. This is followed by a description of a term compression technique using a “tag-on-data” representation. Later derivatives, the Java-based Jinni Prolog compiler and the recently developed Lean Prolog system refine the BinProlog architecture with first-class Logic Engines, made generic through the use of an Interactor interface. An overview of their applications with focus on the ability to express at source level a wide variety of Prolog built-ins and extensions covers these newer developments.

ECLiPSe is a Prolog-based programming system, aimed at the development and deployment of constraint programming applications. It is also used for teaching most aspects of combinatorial problem solving, for example, problem modelling, constraint programming, mathematical programming and search techniques. It uses an extended Prolog as its high-level modelling and control language, complemented by several constraint solver libraries, interfaces to third-party solvers, an integrated development environment and interfaces for embedding into host environments. This paper discusses language extensions, implementation aspects, components, and tools that we consider relevant on the way from Logic Programming to Constraint Logic Programming.

The paradigm of Tabled Logic Programming (TLP) is now supported by a number of Prolog systems, including XSB, YAP Prolog, B-Prolog, Mercury, ALS, and Ciao. The reasons for this are partly theoretical: tabling ensures termination and optimal known complexity for queries to a large class of programs. However, the overriding reasons are practical. TLP allows sophisticated programs to be written concisely and efficiently, especially when mechanisms such as tabled negation and call and answer subsumption are supported. As a result, TLP has now been used in a variety of applications from program analysis to querying over the semantic web. This paper provides a survey of TLP and its applications as implemented in the XSB Prolog, along with discussion of how XSB supports tabling with dynamically changing code, and in a multi-threaded environment.

B-Prolog is a high-performance implementation of the standard Prolog language with several extensions including matching clauses, action rules for event handling, finite-domain constraint solving, arrays and hash tables, declarative loop constructs, and tabling. The B-Prolog system is based on the Tree-Oriented Abstract Machine (TOAM) architecture which differs from the Warren Abstract Machine (WAM) mainly in that (1) arguments are passed old fashionedly through the stack, (2) only one frame is used for each predicate call, and (3) instructions are provided for encoding matching trees. The most recent architecture, called TOAM Jr., departs further from the WAM in that it employs no registers for arguments or temporary variables, and provides variable-size instructions for encoding predicate calls. This paper gives an overview of the language features and a detailed description of the TOAM Jr. architecture, including architectural support for action rules and tabling.

We provide an overall description of the Ciao multiparadigm programming system emphasizing some of the novel aspects and motivations behind its design and implementation. An important aspect of Ciao is that, in addition to supporting logic programming (and, in particular, Prolog), it provides the programmer with a large number of useful features from different programming paradigms and styles and that the use of each of these features (including those of Prolog) can be turned on and off at will for each program module. Thus, a given module may be using, e.g., higher order functions and constraints, while another module may be using assignment, predicates, Prolog meta-programming, and concurrency. Furthermore, the language is designed to be extensible in a simple and modular way. Another important aspect of Ciao is its programming environment, which provides a powerful preprocessor (with an associated assertion language) capable of statically finding non-trivial bugs, verifying that programs comply with specifications, and performing many types of optimizations (including automatic parallelization). Such optimizations produce code that is highly competitive with other dynamic languages or, with the (experimental) optimizing compiler, even that of static languages, all while retaining the flexibility and interactive development of a dynamic language. This compilation architecture supports modularity and separate compilation throughout. The environment also includes a powerful autodocumenter and a unit testing framework, both closely integrated with the assertion system. The paper provides an informal overview of the language and program development environment. It aims at illustrating the design philosophy rather than at being exhaustive, which would be impossible in a single journal paper, pointing instead to previous Ciao literature.

GNU Prolog is a general-purpose implementation of the Prolog language, which distinguishes itself from most other systems by being, above all else, a native-code compiler which produces stand-alone executables which do not rely on any bytecode emulator or meta-interpreter. Other aspects which stand out include the explicit organization of the Prolog system as a multipass compiler, where intermediate representations are materialized, in Unix compiler tradition. GNU Prolog also includes an extensible and high-performance finite-domain constraint solver, integrated with the Prolog language but implemented using independent lower-level mechanisms. This paper discusses the main issues involved in designing and implementing GNU Prolog: requirements, system organization, performance, and portability issues as well as its position with respect to other Prolog system implementations and the ISO standardization initiative.