2.4.1 Prolog 0, Prolog I (1972–1973)

Basic Features: As reported by Cohen (Reference Cohen1988) and later by Colmerauer and Roussel (Reference Colmerauer and Roussel1996), the first system (“Prolog 0”) was written in Algol-W by Roussel in 1972. Practical experience with this system lead to a much more refined second implementation (“Prolog I”) at the end of 1973 by Battani, Meloni, and Bazzoli, in Fortran. This system already had the same operational semantics and most of the built-ins that later became part of the ISO standard, such as the search space pruning operator (the “cut”), relevant for Prolog to become a practical AI language. Efficiency was greatly improved by adopting the structure-sharing technique by Boyer and Moore (Reference Boyer and Moore1972) to represent the clauses generated during a deduction.

Higher-order logic extensions: Basic facilities for meta-programming higher-order logic extensions were present in Prolog systems from the very beginning, and many later systems include extended higher-order capabilities beyond the basic call/1 predicate – for example, $\lambda$ Prolog (Nadathur and Miller Reference Nadathur and Miller1988), BinProlog (Tarau 1992; Reference Tarau2012), Hyprolog (Christiansen and Dahl Reference Christiansen and Dahl2005). Some of the most influential early extensions are discussed into the following subparagraphs.

Constraints: Interestingly, Prolog 0 already included the dif/2 ( $\neq$ ) predicate, as a result of Roussel’s thesis (1972). The predicate sets up a constraint that succeeds if both of its arguments are different terms, but delays the execution of the goal if they are not sufficiently instantiated.

Coroutining: Although dif/2 was neither retained in Prolog I nor became part of the ISO standard, it meant a first step towards the extension of unification to handle constraints: while it introduced the negation of unification, it also allowed an early form of coroutining. Building on this work, Verónica Dahl* introduced a delay meta-predicate serving to dynamically reorder the execution of a query’s elements by delaying a predicate’s execution until statically defined conditions on it become true, and used it to extend Prolog with full coroutining – that is, the ability to execute either a list of goals or a first-order logic formula representing a goal, by proving them in efficient rather than sequential order. With Roland Sambuc, she developed the first Prolog automatic configuration system, which exploited coroutining, for the SOLAR 16 series of computers (Dahl and Sambuc Reference Dahl and Sambuc1976).

Safe Negation as Failure: Dahl also used delay/2 to make negation-as-failure (NaF) (the efficient but generally unsafe built-in predicate of Prolog I which consists of assuming not(p) if every proof of p fails) safe, simply by delaying the execution of a negated goal until all its variables have been grounded. This approach to safe negation and to coroutining made its way into many NL consultable systems, the best known being perhaps Chat 80 (Warren and Pereira Reference Warren and Pereira1982), and more importantly, into later Prologs, as we discuss later.

Deductive Databases: Dahl then ushered in the deductive database field by developing the first relational database system written in Prolog (Dahl 1977; Reference Dahl1982). Other higher-order extensions to Prolog included in this system or in the one by Dahl and Sambuc (Reference Dahl and Sambuc1976), such as list/3 (now called setof/3), have become standard in Prolog.

Metamorphosis Grammars: Metamorphosis Grammars (MGs) (Colmerauer Reference Colmerauer1975) were Colmerauer’s language processing formalism for Prolog. They constituted at the time a linguist’s dream, since they elegantly circumvented the single-head restriction of Prolog’s Horn clauses, thus achieving the expressive power of transformational grammars in linguistics, which, as type-0 formal grammars, allow more than one symbol in their left-hand side. This allowed for fairly direct, while also executable, renditions of the linguistic constraints then in vogue: a single rule could capture a complete parsing state through unification with its left-hand (multi-head) side, in order to enforce linguistic constraints through specifying, in its right-hand side, how to re-write it.

The first applications of MGs were compilation (Colmerauer Reference Colmerauer1975); French consultation of automatic configuration systems (Dahl and Sambuc Reference Dahl and Sambuc1976), where a full first-order logic interlingua was evaluated through coroutining; and Spanish consultation of database systems (Dahl 1977; Reference Dahl1979), where a set-oriented, three valued logic interlingua (Colmerauer Reference Colmerauer1979; Dahl Reference Dahl1979) was evaluated, allowing among other things for the detection of failed presuppositions (Dahl 1977; Reference Dahl1982). Coroutining was used in the system by Dahl and Sambuc (Reference Dahl and Sambuc1976) not only for feasibility and efficiency, as earlier described, but also to permit different paraphrases of a same NL request to be reordered into a single, optimal execution sequence.

A simplification of MGs, Definite Clause Grammars (DCGs), was then developed by Fernando Pereira* and David H.D. Warren*, ^{Footnote 3} in which rules must be single-headed like in Prolog, while syntactic movement is achieved through threading syntactic gap arguments explicitly. DCGs were popularized in 1980 (Pereira and Warren Reference Pereira and Warren1980) and became a standard feature of Prolog. It is worth highlighting that the “DCG” name does not refer to the fact that they can translate to definite clauses (since all four subsets of MGs can, just as a side effect of being included in MGs), but to their restriction to single heads, which makes them similar in shape to definite clauses.

More specialized Prolog-based grammars started to emerge. Their uses to accommodate linguistic theories, in particular Chomskyan, were studied as early as 1984 (Dahl Reference Dahl1986), leading to the new research area of “logic grammars” (Abramson and Dahl Reference Abramson and Dahl1989).

Further Theoretical Underpinnings: In 1978, Keith Clark published a paper that showed NaF to be correct with respect to the logic program’s completion (Clark Reference Clark1978). Simultaneously, Ray Reiter* provided a logical formalization of the related “Closed World Assumption” (Reiter Reference Reiter1978), which underlies NaF’s sanctioning as false of anything that cannot be proved to be true: since in a closed world, every statement that is true is also known to be true, it is safe – in such worlds – to assume that what is not known to be true is false. This then led to substantial research on nonmonotonic reasoning in logic programming, and to inspiring foundational work on deductive databases by Reiter himself, as well as Herve Gallaire*, Jack Minker*, and Jean-Marie Nicolas (1984). The work of Cohen (Reference Cohen1979) on nondeterminism in programming languages was also influential in these early stages.

2.4.2 CDL-Prolog (1975)

As discussed by Peter Szeredi* (Reference Szeredi2004), a group at NIM IGÜSZI in Hungary was trying to port the Marseille system to the locally available machine in 1975. At the same time, Szeredi, who was part of another group at NIM IGÜSZI, completed his first (unnamed) Prolog implementation using the Compiler Definition Language (CDL) developed by Cornelis Koster, one of the authors of the Algol 68 report, marking the beginning of a series of substantial contributions to Prolog.

2.4.3 DEC-10 Prolog (1975)

In 1974, David H.D. Warren visited Marseille and developed a plan generation system in Prolog, called Warplan (Warren Reference Warren1974). He then took Prolog with him as a big deck of punched cards and installed it on a DEC-10 in Edinburgh, where he enhanced it with an alternative “front-end” (or “superviser”) written in Prolog, to better tailor it to the Edinburgh computing environment and the wider character set available (the Marseille group had been restricted by a primitive, upper-case-only, teletype connection to a mainframe in Grenoble). He distributed this version to many groups around the world.

He then set out to address what he perceived as a limitation of the implementations of Prolog up to that point in time: they were comparatively slower and more memory hungry than other high-level AI-languages of the time and, in particular, than LISP. In what would eventually become his PhD thesis work (Warren Reference Warren1977), David H.D. Warren pieced away on one side the elements of Prolog that could be implemented in the same way as the most efficient symbolic programming languages (activation records, argument passing, stack- and heap-based memory management, etc.), and applied to them well-established compilation techniques. Then, for those elements of Prolog that were more novel, such as unification and backtracking, he developed or applied specific compilation and run-time techniques such as optimization of unification by clause head pre-compilation, fast recovery of space on backtracking, trailing, or structure sharing-based term representation (Boyer and Moore Reference Boyer and Moore1972) (the latter already present in Marseille Prolog). He used as target again the DEC-10 with the TOPS-10 operating system, and exploited architectural features of the DEC-10 such as arbitrary-depth indirect memory access, particularly suited for the structure-sharing technique. The product of this effort was the first compiler from Prolog to machine code. This resulted in a large leap in performance for Prolog, both in terms of speed and memory efficiency, rivaling that of Lisp systems. This was documented in Warren et al. (Reference Warren, Pereira and Pereira1977), in what was to be a landmark publication on Prolog in a mainstream Computer Science venue. A version of this compiler dated 1975 is part of the archive maintained by McJones (Reference McJones2021).

Fernando Pereira and Lus Moniz Pereira*, both at LNEC in Lisbon, also made major contributions to the development of the complete DEC-10 Prolog system, which also included now “classic” built-ins such as setof/3 and bagof/3. A significant element in DEC-10 Prolog’s popularity was the availability of an example-rich user guide (Warren Reference Warren1975; Pereira et al. Reference Pereira, Pereira and Warren1978). All these features, coupled with the improved syntax and performance, and the fact that the DEC-10 (and later DEC-20) were the machines of choice at the top AI departments worldwide, made DEC-10 Prolog available to (and used by) all these departments, and in general by the AI research community. This led to DEC-10 Prolog becoming very popular and it spread widely from about 1976 onward. By 1980, the system also featured a garbage collector and last-call optimization (Warren Reference Warren1980). Also in 1980, David H.D. Warren and Fernando Pereira adapted it to TENEX/TOPS-20, which had then become the operating system(s) and machines most widely used for AI research.

The contributions made by the authors of DEC-10 Prolog were fundamental for the coming of age of Prolog: they proved that Prolog could not only be elegant and powerful but it could also come with the usability, speed, and efficiency of a conventional programming language. As a result, DEC-10 Prolog had a large influence on most Prologs after it, and its syntax, now known also as the “Edinburgh syntax,” and many of its features constitute a fundamental component of the current Prolog ISO standard.

However, for all its merits, the one drawback of DEC-10 Prolog was that it was deeply tied to its computer architecture and thereby inherently not portable to new machines, in particular to the then-emerging 32-bit computer architectures with virtual memory. This prompted the development of other, more portable Prologs, described below, and eventually the Warren Abstract Machine (see Section 2.5).

2.4.4 Unix Prolog (1979)

As discussed by Mellish (Reference Mellish1979), there were a number of Prolog interpreters at the time that used the DEC-10 syntax but were internally quite different.

The objective of these other systems was to develop a portable, yet still reasonably-performing Prolog system, written in a mainstream source language, and that could be compiled on more mainstream, 32-bit machines (including later Unix systems such as, for example, the DEC VAX family, which became ubiquitous).

The first system to achieve portability was Unix Prolog by Mellish (Reference Mellish1979), written for PDP-11 computers running Unix, which was also ported to the RT-11 operating system. Unlike Marseille Prolog and DEC-10 Prolog, it used structure-copying rather than structure-sharing. It led to Clocksin and Mellish writing an influential textbook (1981) which describes a standard “core” Prolog, compatible with both DEC-10 Prolog and Unix Prolog.

2.4.5 LPA Prolog (1980)

Logic Programming Associates (LPA) was founded in 1980 out of the group of Kowalski at the Department of Computing and Control at Imperial College London, including, among others, Clive Spenser, Keith Clark, and Frank McCabe (LPA Ltd 2021). LPA distributed micro-PROLOG which ran on popular 8-bit home computers of the time such as the Sinclair Spectrum and the Apple II and evolved to be one of the first Prolog implementations for MS-DOS. LPA Prolog evolved to support the Edinburgh syntax around 1991 and is still delivered today as a compiler and development system for the Microsoft Windows platform.

2.4.6 MU-Prolog (1982)

In 1982, another implementation named MU-Prolog (Naish Reference Naish1982; Naish Reference Naish1986) was developed by Lee Naish at Melbourne University. It was initially a simple interpreter to understand the workings of Prolog, as the author could not find a Prolog system for his hardware.

The system offered efficient coroutining facilities and a delay mechanism similar to those discussed in Section to automatically delay calls to negation and if-then-else constructs, as well as meta-logical (e.g., functor/3) and arithmetic predicates. Its rendition of the delay predicate, here called wait, allows for declarations to be provided manually but also generated automatically.

MU-Prolog was one of the first shipping database connections, module systems, and dynamic loading of shared C libraries, as well as sound negation (through delay/2, as in Section 2.4.1) and a logically pure findall/3 predicate, a consequence of its variable binding-controlled delayed goal execution. MU-Prolog was later succeeded by NU-Prolog (Thom and Zobel Reference Thom and Zobel1987), bringing MU-Prolog’s features to the Warren Abstract Machine (see Section 2.5).

2.4.7 C-Prolog (1982)

As a first foray into getting Edinburgh Prolog on 32-bit address machines, Luís Damas created an Edinburgh-syntax Prolog interpreter for an ICL mainframe with Edinburgh-specific time sharing system (EMAS) and systems programming language (IMP). This interpreter used the structure sharing approach by Boyer and Moore (Reference Boyer and Moore1972) and copied as far as possible the built-in predicates of DEC-10 Prolog. When Fernando Pereira got access to a 32-bit DEC VAX 11/750 at EdCAAD in Edinburgh in 1981, he rewrote EMAS Prolog in C for BSD 4.1 Unix. This required many adaptations from the untyped IMP into the typed C, and he also made it even closer to DEC-10 Prolog in syntax and built-in predicates. The whole project became known as C-Prolog later on (Pereira Reference Pereira1983). The archive maintained by McJones (Reference McJones2021) contains a readme file from 1982.

Although implemented as an interpreter, C-Prolog was reasonably efficient, portable and overall a very usable system. Thus it quickly became influential among the Edinburgh implementations, helping to establish “Edinburgh Prolog” as the standard. It contributed greatly to creating a wider Prolog community and remained extensively used for many years.

2.8.1 The CLP scheme and its early instantiations

CLP was presented by Jaffar and Lassez (Reference Jaffar and Lassez1987) in their landmark paper as a language framework, parameterized by the constraint domain. The fundamental insight behind the CLP scheme is that new classes of languages can be defined by replacing the unification procedure in the resolution steps by a more general process for solving constraints over specific domains. Jaffar and Lassez proved that, provided certain conditions are met by the constraint domain, the fundamental results regarding correctness and (refutation) completeness of resolution are preserved. Traditional LP languages and Prolog are particular cases of the scheme in which the constraints are equalities over the domain of Herbrand terms and can be represented as CLP( ${\cal H}$ ). The CLP framework was first instantiated as the CLP( $\cal R$ ) system (Jaffar et al. Reference Jaffar, Michaylov, Stuckey and Yap1992), which implemented linear equations and inequations over real numbers, using incremental versions of Gaussian elimination and the Simplex algorithm. CLP( $\cal R$ ) was widely distributed, becoming a popular system. In the meantime, the research group at ECRC (the European Computer Research Centre) ^{Footnote 4} developed CHIP (Dincbas et al. Reference Dincbas, Hentenryck, Simonis and Aggoun1988) (for Constraint Handling in Prolog) over the late 1980s, which interfaced Prolog to domain-specific solvers stemming from operations research and successfully introduced constraints over finite domains, CLP( $\mathcal{FD}$ ). CHIP also introduced the concept of global constraints (Beldiceanu and Contejean Reference Beldiceanu and Contejean1994), which is arguably a defining feature of CLP and Constraint Programming. Other instances of the CLP scheme supported constraints over intervals, as implemented by BNR-Prolog (Older and Benhamou Reference Older and Benhamou1993), and constraints over booleans, which are usually implemented as a specialization of finite domains and are useful to express disjunctive constraints, whereby a set of constraints may be placed which encode multiple alternatives, without resorting to Prolog-level backtracking.

2.8.2 Later Marseille Prologs

Prolog III (1990) Colmerauer (Reference Colmerauer1990) focused on improving some limitations of Prolog II. It now included the operations of addition, multiplication, and subtraction as well as the relations $\leq,<,\geq,$ and $>$ . It also improved on the manipulation of trees, together with a specific treatment of lists, a complete treatment of two-valued Boolean algebras, and the general processing of the relation $\neq$ . By doing so, the concept of unification was replaced by the concept of constraint solving in a chosen mathematical structure. By mathematical structure, we mean here a domain equipped with operations and relations, the operations being not necessarily defined everywhere.

Prolog IV (1996) Colmerauer (Reference Colmerauer1996) generalized to discrete and continuous domains the technique of constraint solving by enclosure methods. The solving of an elementary constraint, often qualified local, consists in narrowing the domain ranges of its variables, which generally are intervals. In a system where numerous constraints interact, interval narrowing and propagation is performed iteratively, until a fixed point is reached. It also moved closer to the ISO standard syntax.

2.8.3 Opening the box

While the early instantiations on the CLP scheme, such as CLP( $\cal R$ ), the CLP scheme predecessor Prolog II, BNR Prolog, Prolog III and IV, etc. were all specialized systems, new technology incorporated into Prolog engines for supporting extensions to unification, such as meta-structures (Neumerkel Reference Neumerkel1990) and attributed variables (Holzbaur Reference Holzbaur1992), enabled a library-based approach to supporting embedded constraint satisfaction in standard Prolog systems. This approach was first materialized in Holzbaur’s libraries for supporting CLP over reals, as in CLP( $\cal R$ ), as well as the rationals, CLP( $\cal Q$ ) (Holzbaur Reference Holzbaur1995). On the CLP( $\mathcal{FD}$ ) side, work progressed to replace the segregated “black box” architecture of CHIP by a transparent one (Hentenryck et al. Reference Hentenryck, Saraswat, Deville and Notes1994), in which the underpinnings of the constraint solver are described in user-accessible form (indexicals): such is the proposal discussed and implemented by Diaz and Codognet (Reference Diaz and Codognet1993), Carlson et al. (Reference Carlson, Carlsson and Diaz1994), and Codognet and Diaz (Reference Codognet and Diaz1996). Having elementary constraints to compile to is an approach which has largely been adopted by the attributed variable-based Prolog implementations of CLP( $\mathcal{FD}$ ), present in most Prolog systems. SICStus and GNU Prolog incorporate high-performance native implementations, which nevertheless follow this conceptual scheme.

Constraint Handling Rules (1991, cf. Frühwirth Reference Frühwirth2009, p. xxi) On the trail of providing finer-grained control over the implementation of constraints, Frühwirth (Reference Frühwirth1992); Frühwirth (Reference Frühwirth2009) introduced Constraint Handling Rules (CHR), in which syntactically enhanced Prolog clauses are used to describe and implement the progress of the constraint satisfaction process. CHR is both a theoretical formalism related to first-order and linear logic, and a rule-based constraint programming language that can either stand alone or blend with the syntax of a host language. When the host language is Prolog, CHR extends it with rule-based concurrency and constraint solving capabilities. Its multi-headed rules allow expressing complex interactions succinctly, through rule applications that transform components of a shared data structure: the “constraint store”. A solid body of theoretical results guarantee best known time and space complexity, show that confluence of rule application and operational equivalence of programs are decidable for terminating CHR programs, and show that a terminating and confluent CHR program can be run in parallel without any modification and without harming correctness. Applications are multiple, since CHR, rather than constituting a single constraint solver for a specific domain, allows programmers to develop constraint solvers in any given domain.

It should be noted that CLP has spurred the emergence of a very active research field and community, focusing on Constraints, with or without the Logic Programming part.

2.10.1 Early proprietary Prologs

The WAM aroused much interest and many Prolog implementations started out as an exercise to properly understand it while others were aimed directly at commercialization. Three of the early commercial Prolog systems were Quintus Prolog, BIM-Prolog, and VM/Prolog by IBM.

Quintus Prolog (1984) Shortly after the WAM was proposed, Quintus Computer Systems was founded by David H.D. Warren, William Kornfeld, Lawrence Byrd, Fernando Pereira and Cuthbert Hurd, with the goal of selling a high-performance Prolog system for the emerging 32-bit processors. One of the earliest documents available about Quintus is a specifications note (Warren et al. Reference Warren, Kornfeld and Byrd1984). Quintus used the DEC-10 Prolog syntax and built-ins and was based on the WAM. Currently, Quintus is distributed by SICS (2021). Quintus quickly became the de facto standard at the time, influencing most Prolog systems that were created afterwards. For many years, it offered the highest-performance implementation and was the standard in terms of syntax, built-ins, libraries, and language extensions. Its success inspired many more Prolog systems to emerge, including the ones we discuss below.

BIM-Prolog (1984) In 1984, BIM (a Belgian software house) in cooperation with the Katholieke Universiteit Leuven, and under the guidance of Maurice Bruynooghe, started a project aiming at implementing a commercial Prolog system: BIM-Prolog. A collection of documents is still available on the internet (Bruynooghe Reference Bruynooghe2021) and notable contributions were made among others by Bart Demoen, Gerda Janssens, André Mariën, Alain Callebaut, and Raf Venken. BIM Prolog was funded by the Belgian Ministry of Science Policy and was based on the WAM. One of the earliest resources available is an internal report (Janssens Reference Janssens1984). BIM-Prolog developed into a system with the first WAM-based compiler to native code (as opposed to, e.g., threaded code by Quintus), with interfaces to several database systems (Ingres, Unify, etc.), a graphical debugger in the style of dbxtool, a bidirectional interface to C, decompilation even of static code, and multiargument indexing of clauses – which overcame the common practice of indexing Prolog clauses via their head’s first argument alone. Its first release was on SUN machines, and later it was ported to Intel processors. BIM was involved in the later ISO standardization effort for Prolog. BIM went out of business in 1996.

IBM Prolog (1985) Several Prolog systems that ran on specific IBM hardware remained unnamed and were referred to as IBM Prolog. Here, we focus on Prolog systems distributed by IBM. In 1985, IBM announced a tool named VM Programming in Logic or VM/Prolog (Symonds Reference Symonds1986), which was its Prolog implementation for the 370, focusing on AI research and development. Its development started in 1983 by Marc Gillet at IBM Paris according to Van Roy (Reference Van Roy1994). In 1990, a 16-bit Prolog system for OS/2 was announced, including a database and dialog manager. It was able to call programs written in other IBM languages, such as macro assembler, C/2 and REXX scripts. While its syntax was based on its predecessor, it also provided support for the Edinburgh syntax considering the ongoing ISO standard development. It was maintained until 1992, at which time it was succeeded to by the 32-bit implementation IBM SAA AD/Cycle Prolog/2 (Benichou et al. Reference Benichou, Beringer, Gauthier and Beierle1992). IBM withdrew from the market in 1994.

SICStus Prolog (1986) A preliminary specification of SICStus existed in 1986 (Carlsson Reference Carlsson1986), drawing inspiration from DEC-10 Prolog as well as from Quintus. As already mentioned, SICStus was at first an open-source project aimed at supporting or-parallelism research, and became the basis of much other research, turning into an invaluable tool for other research groups as well as for commercial applications. In addition to the open-source nature, powerful reasons for this popularity were the compatibility with the DEC-10 and Quintus Prolog de-facto standards, very good performance, and compact generated code. Execution profiling and native code compilation were also added later.

At the end of the 80s, the Swedish Funding Agency and several companies funded the industrialization of SICStus, which eventually became a commercial product. In 1998, SICS acquired Quintus Prolog and a number of its features made their way into newer SICStus Prolog versions. SICStus is ISO-conforming and provides support for web-based applications. It also supports several constraint domains, including a powerful finite domain solver. Notably, SICStus is still alive and well as a commercial product, and its codebase is still actively maintained.

2.10.2 Open-source and research-driven Prolog systems based on the WAM

Further, generally open-source Prologs were developed featuring extensions and alternatives arising from the needs of specific application areas or from experimentation with issues such as control, efficiency, portability, global analysis and verification, and, more recently, interoperability and multparadigm support and interaction. This section examines some of these.

YAP Prolog (1985) As further discussed by Costa et al. (Reference Costa, Rocha and Damas2012), the YAP Prolog project started in 1985. In contrast to other systems discussed here, early versions of it were cast as a proprietary system which was later released as open source software. Luís Damas, the main developer, wrote a Prolog compiler and parser in C (still used today). Since the emulator was originally written in m68k assembly, the result was a system that was and felt fast. As the 68k faded away, Damas developed a macro language that could be translated into VAX-11, MIPS, Sparc, and HP-RISC. Unfortunately, porting the emulator to the x86 was impossible, so a new one was designed in C, making it also easier for some excellent students to contribute. Rocha implemented the first parallel tabling engine (Rocha et al. Reference Rocha, Silva and Costa2005) and Lopes the first Extended Andorra Model emulator (Lopes et al. Reference Lopes, Costa and Silva2012). This work was well received by the community, but proved difficult to use in scaling up real applications. The problem seemed to be that many YAP applications used Prolog as a declarative database manager. In order to support them, the team developed JITI (Costa et al. Reference Costa, Sagonas, Lopes and Notes2007), a just-in-time multiargument indexer that uses any instantiated arguments to choose matching clauses, hoping to avoid shallow backtracking through thousands or millions of facts. JITI’s trade-off is extra space – the mega clause idea reduces overhead by compacting clauses of the same type into an array (Costa Reference Costa2007), and the exo-emulation saves space by having a single “smarter” instruction to represent a column of a table (Costa and Vaz Reference Costa and Vaz2013).

Ciao Prolog (1993) a.k.a. &-Prolog (1986) As mentioned before, &-Prolog started in 1986, based initially on early versions of SICStus. The early 90s brought much evolution, leading to its re-branding as Ciao Prolog (Hermenegildo and CLIP Group 1993). One of the main new aims was to point out future directions for Prolog, and to show how features that previously required a departure from Prolog (such as those in, e.g., Mercury, Gödel, or AKL, and from other paradigms), could be brought to Prolog without losing Prolog’s essence. A new module system and code transformation facilities were added that allowed defining many language extensions (such as constraints, higher-order, objects, functional notation, other search and computation rules, etc.) as libraries in a modular way (Hermenegildo et al. 1994; Hermenegildo et al. Reference Hermenegildo, Bueno, Cabeza, Carro, Garcia de la Banda, Lãpez-García and Puebla1996; Cabeza and Hermenegildo Reference Cabeza and Hermenegildo2000), and also facilitated global analysis. Also, the progressively richer information inferred by the PLAI analyzers was applied to enhancing program development, leading to the Ciao assertion language and pre-processor, CiaoPP (Hermenegildo et al. Reference Hermenegildo, Puebla and Bueno1999; Puebla et al. Reference Puebla, Bueno and Hermenegildo2000a; Hermenegildo et al. Reference Hermenegildo, Puebla, Bueno and Garcia2005), which allowed optionally specifying and checking many properties such as types, modes, determinacy, nonfailure, or cost, as well as auto-documentation. A native, optimizing compiler was also developed, and the abstract machine was rewritten in a restricted dialect of Prolog, ImProlog (Morales et al. Reference Morales, Carro, Puebla and Hermenegildo2005; Morales et al. Reference Morales, Carro and Hermenegildo2016).

SB-Prolog (1987) SB-Prolog was a Prolog system that, according to the CMU Artificial Intelligence Repository (1995) became available in 1987, and had been started as an exercise to understand the WAM. It was made freely available in the hope that its source code would be of interest to other Prolog researchers for understanding, use, and extension. Indeed, it became the foundation of two other Prolog systems, XSB (cf. Section) and B-Prolog (cf. Section 2.11). The goal of XSB Prolog (Sagonas et al. Reference Sagonas, Swift and Warren1994) at its release in 1993 was to allow new application areas of Prolog. As an example, a recent survey of its applications to NLP is given by Christiansen and Dahl (Reference Christiansen and Dahl2018).

Andorra I (1991) Sometimes also referred as Andorra Prolog, Andorra I is a Prolog system developed by Costa et al. (Reference Costa, Warren and Yang1991). This system exploited both (deterministic) AND-parallelism and OR-parallelism, while also providing a form of implicit coroutining, and ran on the shared-memory multiprocessors of the time, the Sequent Symmetry. OR-parallelism was supported by using binding arrays to access common variables and the Aurora scheduler (Lusk et al. Reference Lusk, Butler, Disz, Olson, Overbeek, Stevens, Warren, Calderwood, Szeredi, Haridi, Brand, Carlsson, Ciepielewski and Hausman1990). The implementation of AND-parallelism, that (dynamically) identified which goals in a clause are determinate and can be evaluated independently in parallel, came to be known as the Andorra Principle and is akin to the concept of sidetracking (Pereira and Porto Reference Pereira and Porto1979), itself a form of coroutining. Adherence to Prolog operational semantics meant that subgoal order sometimes needs to remain fixed and, also, that a cut may impact parallel execution. Implementing an efficient Prolog system which could exploit both forms of parallelism led to difficulties, for which solutions would follow in the guise of different computational models, namely the Extended Andorra Model (Warren Reference Warren1990) and the Andorra Kernel Language (AKL) (Janson and Haridi Reference Janson and Haridi1991).

GNU Prolog (1999) a.k.a. Calypso (1996), and wamcc (1992) As stated on the GNU Prolog home page (GNU Prolog Reference Prolog2021), the development of GNU Prolog started in January 1996 under the name Calypso. A few years later, in 1999, the first official release of GNU Prolog saw the light (Diaz et al. Reference Diaz, Abreu and Codognet2012).

GNU Prolog is derived from wamcc (Codognet and Diaz Reference Codognet, Diaz and Press1995), a system developed in 1992–1993 as a foundational framework for experiments on extensions to Prolog, such as intelligent backtracking techniques, coroutining, concurrency, and constraints. The wamcc Prolog system was designed to be easily maintainable, lightweight, portable, and freely available, while still reasonably fast. Its approach consisted in using the WAM as an intermediate representation in a multipass compilation process, producing C code which was subsequently compiled by GCC, to yield native code which was then linked to produce an executable. wamcc was used as the basis for the development of CLP( $\mathcal{FD}$ ) (Codognet and Diaz Reference Codognet and Diaz1996), which introduced transparent user-defined propagators for finite domain ( $\mathcal{FD}$ ) constraint solving (CLP). In a later stage, when the ISO standard was being introduced in 1995, the CLP( $\mathcal{FD}$ ) system was redesigned to become more standards-compliant and to increase its compile-time performance to compete with that of interpreted Prolog systems. As C was used as the intermediate language, compiled Prolog programs would map to considerably larger C programs which were very slow to compile using GCC, with little benefit as the code had very explicit and low-level control flow (e.g., labels and gotos.) This situation led to the replacement of C by a much simpler specialized miniassembly language (Diaz and Codognet Reference Diaz and Codognet2000) as the intermediate language for compiling Prolog. After it was approved by the Free Software Foundation, this system became GNU Prolog.

$\mathrm{ECL}^{i}\mathrm{PS}^e$ (1993)

The earliest resource about the $\mathrm{ECL}^{i}\mathrm{PS}^e$ logic programming system (Schimpf and Shen Reference Schimpf and Shen2012) is the technical paper by Wallace and Veron (Reference Wallace and Veron1993). Originally, it was an integration of ECRC’s SEPIA, an extensible Prolog system, Mega-Log, an integration of Prolog and a database, and (parts of the) CHIP systems. It was then further developed into a Constraint Logic Programming system with a focus on hybrid problem solving and solver integration. It is data driven, allowing for array syntax and structures with field names. The system also contains a logical iteration construct that eliminates the need for most of the basic recursion patterns. Since September 2006, $\mathrm{ECL}^{i}\mathrm{PS}^e$ is an open-source project owned by Cisco.

3.3.1 Core features

Module System As mentioned before, while most Prolog systems support structuring the code into modules, virtually no implementation adheres to the modules part of the ISO standard. Instead, most systems have decided to support as de-facto module standard the Quintus/SICStus module system. However, further convenience predicates concerning modules are provided by some implementations only and often have subtle differences in their semantics.

Interesting cases include GNU Prolog which initially chose not to implement a module system at all, although a similar functionality was later brought in by means of contexts and dynamic native unit code loading (Abreu and Nogueira Reference Abreu and Nogueira2005); Logtalk which demonstrates that code reuse and isolation can be implemented on top of ISO Prolog using source-to-source transformation (Moura Reference Moura2003); Ciao which designed a strict module system that, while being basically compatible with the de-facto standard used by other Prolog systems, is amenable to precise static analysis, supports term hiding, and facilitates programming in the large (Cabeza and Hermenegildo Reference Cabeza and Hermenegildo2000; Stulova et al. Reference Stulova, Morales and Hermenegildo2018); and XSB, which offers an atom-based module system (Sagonas et al. Reference Sagonas, Swift and Warren1994). The latter two systems allow controlling the visibility of terms in addition to that of predicates.

Built-in Data Types The ISO Prolog standard requires support for atoms, integers, floating-point numbers, and compound terms with only little specification on the representation limits, usually available as Prolog flags.

In practice, most limits evolve with the hardware (word length, floating-point units, available memory, and raw performance), open software libraries (e.g., multiple precision arithmetic), and system maturity. Since the standard does not specify minimum requirements for limits, special care must be taken in the following cases:

• Integers may differ between Prolog systems. E.g., a given system may not support arbitrary precision arithmetic. Furthermore, the minimum and maximum values representable in standard precision may be smaller than implied by word length (due to tagging).

• Maximum arity of compound terms may be limited (max_arity Prolog flag). Despite the arity of user terms usually falling within the limits, this is an issue with automatic program manipulation (e.g., analyzers) or libraries representing arrays as terms.

• Atoms have many implementation-defined aspects, such as their maximum length, number of character codes (such as ASCII, 8-bit or Unicode), text encoding (UTF-8 or other), whether the code-point 0 can be represented, etc.

• Strings are traditionally represented as list of codes or characters (depending on the value of double_quotes flag), or as dedicated data types. Although this can be regarderd as very minor issue, combining different pieces of code expecting different encodings is painful and error prone.

• Garbage collection of atoms may not be available. This may lead to nonportability due to resource exhaustion in programs that create an arbitrary number of atoms.

• Floating point numbers are not specified to be represented in a specific way. The IEEE double standard is most prevalent across all Prolog systems. However, support for constants such as NaN, -0.0, Inf as well as rounding behavior may differ. $\mathrm{ECL}^{i}\mathrm{PS}^e$ , for example, does interval arithmetic on the bounds.

For convenience, systems may offer other data types by means of (nonstandard) extension of the built-in data types, for example, rational numbers (useful for the implementation of CLP( $\cal Q$ )), key-value dictionaries, and compact representations of strings. There is no consensus on those extensions or portable implementation mechanisms, thus more work is needed in this area.

Foreign (Host) Language Interface Like any programming language, Prolog is more suited for some problems than for others. With a foreign language interface, it becomes easier to embed it into a software system, where it can be used to solve part of a problem or access legacy software and libraries written in another language. Since this is also a nonstandard feature, the interfaces themselves, as well as the targeted languages, differ quite a lot among different systems. An important case is interfacing Prolog with the host implementation language of the system (e.g., C, Java, JavaScript). The main issues revolve around the external representation for Prolog terms (usually in C or Java) and whether nondeterminism is visible to the host language or should be handled at the Prolog level. The latter aspect is usually resolved by hiding backtracking from the foreign language program, except in where there is a natural counterpart: such is the case when the language has consensual built-in support for features like iterators. A more detailed survey describing and comparing different features is given by Bagnara and Carro (Reference Bagnara and Carro2002).

3.3.2 Libraries

Constraint Satisfaction As mentioned in Section 2.8, advances such as finite domain implementation based on indexicals and, specially, progress in the underlying technology in Prolog engines for supporting extensions to unification, such as meta-structures (Neumerkel Reference Neumerkel1990) and attributed variables (Holzbaur Reference Holzbaur1992), enabled the library-based approach to supporting embedded constraint satisfaction that is now present in most Prolog systems. Since many constraint domains have been implemented as libraries, such as $\cal R$ and $\cal Q$ (linear equations and inequations over real or rational numbers), $\mathcal{FD}$ (finite domains), $\cal B$ (booleans), etc.

Systems vary in how the constraint satisfaction process gets implemented. In SICStus and $\mathrm{ECL}^{i}\mathrm{PS}^e$ , the constraint library is partly implemented in C, in the case of GNU Prolog in a dedicated DSL designed to specify propagators. Several other systems, such as Ciao, SWI-Prolog, XSB, and YAP, use Prolog implementations built on top of attributed variables (as mentioned above), such as those of Holzbaur (Reference Holzbaur1992) or Triska (Reference Triska2012), or local ones. While the C-based implementations provide a performance edge, the Prolog implementations are small, portable, and may use unbounded integer arithmetic when provided by the host system.

CHR (Frühwirth Reference Frühwirth2009), described also in Section 2.8.3, is available in several Prolog systems as a library which, rather than working on a single, specific domain, enables the writing of rule-based constraint solvers in arbitrary domains. CHR provides a higher-level way of specifying propagation and simplification rules for a constraint solver, although possibly at some performance cost.

Data Structures Different Prolog systems also ship varying numbers of included libraries such as code for AVL trees, ordered sets, etc. Because they are usually written purely in standard Prolog, those implementations can usually be dropped in place without larger modifications.

3.3.3 Extensions

Tabling As discussed in Section 2.9, tabling can be used to improve the efficiency of Prolog programs by reusing results of predicate calls that have already been made, at the cost of additional memory. It improves the termination properties of Prolog programs by delaying self-recursive calls. Tabling was first implemented in XSB and currently a good number of other Prolog implementations support it (e.g., B-Prolog, Ciao, SWI, YAP). XSB and recent SWI-Prolog versions improve support for negation using stratified negation and well-founded semantics. Both systems also provide incremental tabling which automatically updates tables that depend on the dynamic database, when the latter is modified. Some systems (YAP, SWI-Prolog) support shared tabling which allows a thread to reuse answers that are already computed by another thread. Ciao supports a related concept of concurrent facts for communication between threads (Carro and Hermenegildo Reference Carro and Hermenegildo1999), combines tabling and constraints (Arias and Carro Reference Arias and Carro2016), and supports negation based on stable model semantics (Arias et al. Reference Arias, Carro, Salazar, Marple and Gupta2018).

Parallelism Today, new hardware generations do not generally bring large improvements in sequential performance, but they do often bring increases in the number of CPU cores. However, ISO-Prolog only specifies semantics for single-threaded code and does not specify built-ins for parallelism. As already discussed in Section 2.7, several parallel implementations of Prolog or derivatives thereof have been developed, targeting both shared-memory multiprocessors and distributed systems. Support for or-parallelism is not ubiquitous nowadays, although systems like SICStus were designed to support it and this feature can possibly be easily recovered. Ciao still has some native support for and-parallelism and concurrency, and its preprocessor CiaoPP still includes auto-parallelization. A different, more coarse-grained form of parallelism is multithreading (this is what the parallelism column in Table 2 gathers).

Indexing Indexing strategies of Prolog facts and rules are vital for Prolog development as they immediately influence how Prolog predicates are written with performance in mind. The availability of different indexing strategies is an important issue that affects portability of Prolog programs: if a performance-critical predicate cannot be indexed efficiently, run-time performance may be significantly affected. There are several strategies for indexing:

• First-argument (FA) indexing is the most common strategy where the first argument is used as index. It distinguishes atomic values and the principal functor of compound terms.

• Nonfirst argument indexing is a variation of first-argument indexing that uses the same or similar techniques as FA on one or more alternative arguments. E.g., if a predicate call uses variables for the first argument, the system may choose to use the second argument as the index instead.

• Multiargument (MA) indexing creates a combined index over multiple instantiated arguments if there is not a sufficiently selective single argument index.

• Deep indexing is used when multiple clauses use the same principal functor for some argument. It recursively uses the same or similar indexing techniques on the arguments of the compound terms.

• Trie indexing uses a prefix tree to find applicable clauses.

In addition to the above indexing techniques, one can also distinguish systems that use directives to specify the desired indexes and systems that build the necessary indexes just-in-time based on actual calls. One should note that the first form of indexing (FA) is the only one which may be effectively relied upon when designing portable programs, for it is close to universal adoption.

Type and Mode Annotations As Prolog is a dynamic language, it can be hard to maintain larger code bases without well-defined (and checkable) interfaces. Several approaches have been proposed to achieve or enforce sound typing in Prolog programs (Mycroft and O’Keefe Reference Mycroft and O’Keefe1984; Dietrich and Hagl 1988;; Gallagher and Henriksen Reference Gallagher and Henriksen2004; Schrijvers et al. Reference Schrijvers, Costa, Wielemaker and Demoen2008). While these approaches are closer to strong typing, they have not caught on with mainstream Prolog.

Many Prolog systems offer support, for example, for mode annotations, yet the directives usually have no effects except their usage for documentation. The few Prolog or Prolog-like systems that really address these issues and incorporate a type and mode system include Mercury (Somogyi et al. Reference Somogyi, Henderson and Conway1996) and Ciao (Hermenegildo et al. Reference Hermenegildo, Puebla and Bueno1999). The former is rooted in the Prolog tradition, but departs from it in several significant ways (see Sections 2.1 and 3.5). The latter aims to bridge the static and dynamic language approaches, while preserving full compatibility with traditional nonannotated Prolog. A fundamental component is its assertion language (Puebla et al. Reference Puebla, Bueno and Hermenegildo2000b) that is processed by CiaoPP (cf. Section 2.10.2). CiaoPP then is capable of finding nontrivial bugs statically or dynamically and can statically verify that the program complies with the specifications, even interactively (Sanchez-Ordaz et al. Reference Sanchez-Ordaz, Garcia-Contreras, Perez-Carrasco, Morales, Lopez-Garcia and Hermenegildo2021). The Ciao model can be considered an antecedent of the now-popular gradual- and hybrid-typing approaches (Flanagan Reference Flanagan2006; Siek and Taha Reference Siek and Taha2006; Rastogi et al. Reference Rastogi, Swamy, Fournet, Bierman and Vekris2015) in other programming languages.

Coroutining As discussed in Section 2.4.1, coroutining was first introduced into Prolog in order to influence its default left-to-right selection rule. From a logical perspective, logic programs are independent of the selection rule. However, from a practical, programming language perspective, procedural factors might influence efficiency, termination, and even faithfulness to the intended results. Consider for instance a program that tries to calculate the price of an as yet unknown object X (this could result from, say, some natural language interface’s ordering of different paraphrases). Coroutining can ensure that the program behaves as intended by reordering these goals so that objects are instantiated before attempting to calculate their prices.

Coroutining is an important feature of modern Prolog systems, allowing programmers to write truly reversible predicates and improve their performance. It represents a step forward towards embodying the equation of “Algorithm = Logic + Control” by Kowalski (Reference Kowalski1979). Early mechanisms for coroutining focused on variations of the delay primitive by Dahl and Sambuc (Reference Dahl and Sambuc1976), which dynamically reorders the execution of predicates according to statically, user-defined conditions on them. The freeze variation was present in Prolog II (Colmerauer Reference Colmerauer1982b; Boizumault Reference Boizumault1986), which delays the execution of its second argument (understood to be a goal) until its first argument, a single variable occuring in the second argument, is bound. A more flexible variation is the wait primitive present in MU-Prolog (Naish Reference Naish1985), which was subsequently generalized to when. This concern evolved into the block declaration found in modern Prologs, which supports the annotation of an entire predicate (rather than of each individual call), resembling a mode declaration. This approach thus leads to more readable programs and more efficient code. It can be argued that the coupling of goal evaluation to the binding of variables ultimately led to the development of Constraint Logic Programming (CLP) (3.3.2).

3.3.4 Tools

Unit Testing Structures One of the most important tools in software development is a proper testing facility. Some Prolog systems ship a framework for unit testing, and while the basic functionality is shared, usually they do not adhere to the same interface. SWI-Prolog ships a library named plunit, while SICStus uses a modified version of it. Both versions are entirely written in Prolog, yet they rely on system-specific code to function properly. Ciao relies on the test assertions of its assertion language, which also include test case generation. $\mathrm{ECL}^{i}\mathrm{PS}^e$ offers a library named test_unit with several test primitives that assert whether calls should succeed, raise errors, etc. Other systems seem to rely on the fact that a small ad hoc testing facility is rather easy to implement.

Debugging A good debugger is vital to understand and fix undesired behaviors of programs. Prolog control flow is different from that of most other programming languages because it has backtracking. To address this, most Prolog systems provide some form of tracing debugger based on the 4-port debugger introduced for DEC-10 Prolog by Byrd (Reference Byrd1980), which allows for the tracing of individual goals at their call, exit, redo, and failure ports (states). Most systems allow setting of spy points (similar to breakpoints) and some provide a very Prolog-specific and powerful debugging tool: the retry command which allows one to “travel back in time” to the entry point of a call that, for some reason, misbehaved. The latter feature assumes Prolog programs without side effects. A few systems, such as SWI, SICStus, and Ciao, additionally offer source-level debugging that allows following the steps of execution directly on the program text, thus providing a more conventional view.

Available and Mostly Compatible Features

Mostly compatible module systems have been widely adopted, even if they virtually all diverge from the ISO document. The existence of a de-facto module standard makes it possible to write production-quality libraries that are portable across most Prolog systems. Facilities for multithreaded programming are also common: A number of systems offer predicates based on the corresponding technical recommendation document (Moura Reference Moura2007), sometimes with some differences in semantics or syntax.

Most systems also offer libraries for constraint programming, though they differ in performance and expressiveness. Yet, no standard interface or even a proposal for one exists.

Almost all Prolog systems embrace dynamic typing, and type and mode annotations are used for documentation or optimization, yet are not enforced or verified at all. Ciao, with its combination of the dynamic and static approaches, is the significant exception here.

While support for tabling is present in various systems, the features and interfaces can differ. Programs that rely on it (beyond simple answer memoization that can be implemented fairly simply using the dynamic database), specially if they use special features, can be hard to port. Thus, progress needs to be made toward better portability in this area.

Discrepancies

One gets a mixed result when considering support for other features: some systems, such as $\mathrm{ECL}^{i}\mathrm{PS}^e$ offer extensive library support of data structures, whereas others remain rather basic, without a large standard library.

Coroutining is not available on all systems, and the various primitives (when, block, freeze, dif) sometimes have some variations among those systems that do support it. A similar situation occurs for global variables and mutable terms. Similarly, testing frameworks are missing in several systems, but usually can be provided in form of a portable library.

Almost all Prolog systems support at least one foreign language interface, in order to leverage existing libraries and to widen the domains where logic programming can be applied. Yet, there are different strategies on how the interfaces interact with Prolog, and, thus, the interfaces often differ between implementations.

An issue that can also hinder portability is the large discrepancy in indexing strategies. Solutions so far are of a very technical nature, rather than aimed toward a common interface, so work is needed if this issue is to be resolved.

Ease of Expression

Prolog is a language with a small core and a minimal, yet extremely flexible syntax. Even though some features can only be understood procedurally, such as the cut, the semantics remains very simple. Combined with automatic memory management and the absence of pointers or uninitialized terms makes Prolog a particularly safe language. Flexible dynamic typing completes the picture by placing Prolog among the most high-level programming languages available to date – a feature that makes it very close to how humans think and reason, and therefore ideal for Artificial Intelligence (AI).

The inspection and manipulation of programs at run-time also leads to faster programmer feedback and enables powerful debugging, in particular when coupled with Prolog’s interactive toplevel (a.k.a. REPL or Read-Eval-Print-Loop, although in the case of Prolog the print part is richer because of multiple solutions).

Declarativity is yet another important feature of Prolog: most programs just state what the computer should do and let the Prolog engine figure out the how. For pure logic programs, the resolution strategy may also be altered, and possibly optimized, without requiring the source code of those programs to be changed. Program analysis and transformation tools, partial evaluators, and automatic parallelizers can be used for Prolog programs and can be particularly effective for purely declarative parts. For partial evaluation, however, the techniques have still not yet been integrated into Prolog compilers (the discussion by Leuschel and Bruynooghe Reference Leuschel and Bruynooghe2002, Section 7 is mostly still valid today), with the exception of Ciao Prolog’s preprocessor (Hermenegildo et al. Reference Hermenegildo, Puebla, Bueno and Garcia2005) and abstract machine generator (Morales et al. Reference Morales, Carro, Puebla and Hermenegildo2005; Morales et al. Reference Morales, Carro and Hermenegildo2016). However, they have found their way into just-in-time compilers for other languages (Bolz et al. Reference Bolz, Cuni, Fijalkowski, Leuschel, Pedroni and Rigo2011).

Prolog’s data structure creation, access, matching, and manipulation are performed via the powerful and efficiently implemented unification operation. The logical terms used by Prolog as data structures are managed dynamically and efficiently. Logical variables within logical terms can encode “holes,” which can then be passed around arbitrarily and filled at other places by a running program. Furthermore, logical variables can be bound (aliased) together, closing or extending pointer chains. This gives rise to many interesting programming idioms such as difference lists and difference structures, and in general to all kinds of pointer-style programming, where logical variables serve as “declarative pointers” (since they can be bound only once). This view of logical variables as declarative pointers and related issues have been discussed by Hermenegildo (Reference Hermenegildo2000). Furthermore, Prolog’s automatic memory management ensures the absence of nuisances such as NullPointer exceptions or invalid pointer manipulations. Many Prolog systems also come with arbitrary precision integers, which are used transparently without requiring user guidance.

Prolog compilers and the many program analysis and transformation tools mentioned above are almost always written in Prolog itself, which is an excellent language for writing program processors. Interestingly, since the semantics of programming languages can be easily encoded as (Constraint) Horn Clauses (CHCs), Prolog tools can often be applied directly to the analysis of other languages (Méndez-Lojo et al. Reference Méndez-Lojo, Navas and Hermenegildo2007). The survey by De Angelis et al. (Reference De Angelis, Fioravanti, Gallagher, Hermenegildo, Pettorossi and Proietti2021) in this same special issue of the TPLP journal provides a comprehensive overview of work using analysis and transformation of (constrained) Horn clauses and techniques stemming from logic programming for program verification, including those techniques most related to Prolog.

Efficiency

In addition, Prolog is a surprisingly efficient language. Beginners will often write very inefficient Prolog programs. Yet, carefully written Prolog programs can build on many of the features provided by modern implementations, such as last call optimization (which generalizes tail recursion optimization), efficient indexing and matching, and fine-tuned memory management with efficient backtracking. For applications which are well-suited to Prolog, such as program analysis (Méndez-Lojo et al. Reference Méndez-Lojo, Navas and Hermenegildo2007), program verification (Leuschel Reference Leuschel2008), or theorem proving (see Section 3.5.2), this can lead to programs which are both more flexible and better-performing than counterparts written in traditional languages (Leuschel Reference Leuschel2020).

Successful Applications

Thanks to its simple foundation, the language makes it straightforward to read Prolog programs as data objects and it is almost trivial to implement meta-interpreters, as well as custom or domain-specific languages (such as Erlang Armstrong Reference Armstrong2007, which was initially implemented in Prolog). Therefore, it can be (and has been) used as a means to represent knowledge bases or bootstrap declarative languages in knowledge-intensive environments. Prolog has also been used for several successful formal methods tool developments, such as, for example, Leuschel and Butler (Reference Leuschel and Butler2008), Lopez-Garcia et al. (Reference Lopez-Garcia, Darmawan, Klemen, Liqat, Bueno and Hermenegildo2018). Moreover, Prolog supports the implementation of novel sorts of expert systems or logic solvers, relying for instance on probabilistic, abductive, or inductive inference, which can be simply realized as meta-interpreters. This is another reason why Prolog is well suited for symbolic AI applications. It can also be used to integrate and reason over heterogeneous data (Wielemaker et al. Reference Wielemaker, Hildebrand, van Ossenbruggen and Schreiber2008).

Prolog has also been successfully used for parsing, both for computer languages and for natural languages (see also Section 2.4.1). A relatively recent success story is IBM’s Watson system (Lally et al. Reference Lally, Prager, McCord, Boguraev, Patwardhan, Fan, Fodor and Chu-Carroll2012) which used Prolog for natural language processing, adapting techniques developed in logic grammars over the years for solving difficult computational linguistics problems, such as coordination (McCord Reference McCord2006; Dahl and McCord Reference Dahl and McCord1983). Regarding parsing algorithms, Prolog’s renditions of tabling admit especially succinct while elegant and efficient formulations, as demonstrated for the CYK algorithm on p. 37 of Frühwirth’s book on CHR (Frühwirth Reference Frühwirth2009). Indeed, Prolog lends itself particularly well for grammar development and grammatical theory testing, which has potential both for compilers and for spoken and other human languages. The simplest grammatical Prolog version, DCGs, extends context-free grammars with symbol arguments, while the first grammatical version, MGs, extends type-0 grammars with symbol arguments. Variants that are adequate to different linguistic theories can, and have been, developed (Dahl Reference Dahl1992; Dahl et al. Reference Dahl, Popowich and Rochemont1993; Dahl 1990; Reference Dahl1986). Most crucially, semantics can be straightforwardly accommodated and examined through symbol arguments, which allows for the increasingly important features of transparency and explainability to materialize naturally. Coupled with Prolog’s meta-programming abilities, grammar transformation schemes can help automate the generation of linguistic resources that most languages in the world typically lack, as shown by Dahl and Miralles (Reference Dahl and Miralles2012). Finally, tabling can be used for efficient parsing (Simpkins and Hancox Reference Simpkins and Hancox1990) of a wide range of grammars, even context-sensitive ones. Many more examples of practical applications can be found in the literature, in particular in the conference series PADL (Practical Applications of Declarative Languages, running since 1999) and INAP (International Conference on Applications of Declarative Programming and Knowledge Management, since 1998). ICLP, the premier conference in logic programming, regularly includes papers and sessions on applications and some editions have a special applications track.

Active Community

As we have seen throughout this paper, there are many implementations of the Prolog language, many of them quite mature and still being actively developed, with new features and libraries added continuously, while new implementations keep appearing, with new aims or targeting different niches.

There are many books and tutorials on the Prolog language. Good examples are texts by Clocksin and Mellish (Reference Clocksin and Mellish1981), Sterling and Shapiro (Reference Sterling and Shapiro1994), O’Keefe (Reference O’Keefe1990), Clocksin (Reference Clocksin1997), Blackburn et al. (Reference Blackburn, Bos and Striegnitz2006), Bratko (Reference Bratko2012), or Triska (Reference Triska2021). There is also significant teaching material publicly available in the form of slides, exercises, examples, contest problems, etc., as well as plenty of topical discussions in on-line fora. There are also some interactive learning environments and playgrounds, for example, GUPU (Neumerkel and Kral Reference Neumerkel and Kral2002), or those of SWI, Ciao, or LogTalk, although this is certainly an area that would be well worth improving.

A Prolog programming contest (which has now expanded to include other LP and CLP dialects) is held every year in the context of ICLP.

Even with Prolog being somewhat outside the mainstream of programming languages, it is taught at many universities for a simple reason: it introduces new concepts and features that are quite different from those of object-oriented as well as functional programming languages. Accordingly, it provides computer scientists with not only a simple yet powerful tool to understand and write elegant algorithms but also a new way of thinking about programming. Getting to know the ropes of Prolog expands one’s horizons and allows programmers to significantly improve their way of solving problems. One could easily argue that a computer scientist is not really complete without being familiar with First-Order Logic, Resolution, Logic Programming, and Prolog.

Artificial Intelligence

Symbolic AI: Prolog is undoubtedly among the most impactful ideas in symbolic AI. However, subsymbolic or data-driven AI is nowadays attracting most of the attention and resources, mostly because of the recent progress that has been achieved in machine and deep learning.

Despite these advances, state-of-the-art data-driven AI techniques are far from perfect. A common problem that shows up in critical fields such as Healthcare (Panch et al. Reference Panch, Mattie and Atun2019), Finance (Johnson et al. Reference Johnson, Pasquale and Chapman2019), or Law (Tolan et al. Reference Tolan, Miron, Gómez and Castillo2019) is that learning-based solutions tend to acquire the inherent biases of the contexts they are trained into. This often results in decision support systems exposing sexist, racist, or discriminatory behaviors, thus unwittingly permeating the digital infrastructure of our societies (Noble Reference Noble2018).

Similarly, subsymbolic techniques have been criticized for their inherent opacity (Guidotti et al. Reference Guidotti, Monreale, Turini, Pedreschi and Giannotti2019). In fact, while most techniques in this field (neural networks, support vector machines, etc.) are very good at learning from data, they easily fall short when it comes to explicitly representing what they have learned. For this reason, such techniques are often described as black boxes in the literature (Lipton Reference Lipton2018).

Explainable AI: While all such issues are being tackled by the eXplainable AI community (XAI) (Gunning Reference Gunning2016) by using a plethora of subsymbolic tricks (Guidotti et al. Reference Guidotti, Monreale, Turini, Pedreschi and Giannotti2019), an increasing number of works recognize the potential impact of symbolic AI models and technologies in facing these issues, such as the works by Calegari et al. (Reference Calegari, Ciatto, Mariani, Denti and Omicini2018, Reference Calegari, Ciatto and Omicini2020) or Cyras et al. (Reference Cyras, Rago, Albini, Baroni and Toni2021). It seems clear that symbolic inferential capabilities will be crucial for transitioning into the sustainable and humanity-serving AI that is urgently needed (Calegari et al. Reference Calegari, Ciatto and Omicini2020). Accordingly, we highlight two possible research directions where Prolog and LP may contribute further to the current AI picture. One direction concerns the exploitation of LP either (i) for making machine and deep learning techniques more interpretable or (ii) for constraining their behavior, reducing biases. There, Prolog and LP may be exploited as a lingua franca for symbolic rules extracted from subsymbolic predictors (Calegari et al. Reference Calegari, Ciatto, Dellaluce and Omicini2019; Ciatto et al. Reference Ciatto, Schumacher, Omicini, Calvaresi and Notes2020), or as a means to impose constraints on what a subsymbolic predictor may (or may not) learn (Serafini et al. Reference Serafini, Donadello, d’Avila Garcez, Seffah, Penzenstadler, Alves and Peng2017). The other direction concerns the exploitation of subsymbolic AI as a means to speed up or improve some basic mechanism of LP and Prolog. For example, in the field of inductive logic programming (Muggleton and de Raedt Reference Muggleton and de Raedt1994) neural networks have been exploited to make the inductive capabilities of induction algorithms more efficient or effective (d’Avila Garcez and Zaverucha Reference d’Avila Garcez and Zaverucha1999; Basilio et al. Reference Basilio, Zaverucha and Carneiro Barbosa2001). For instance, in the work of França et al. (Reference FranÇa, Zaverucha and d’Avila Garcez2014), the induction task is translated into an attribute-value learning task by representing subsets of relations as numerical features, and CILP++ neuro-symbolic system is exploited to make the process faster.

Along this path, more general approaches attempt to unify, integrate, or combine the symbolic and subsymbolic branches of AI, for the sake of advancing the state of the art. This is the case for instance of the neuro-symbolic initiatives (de Raedt et al. Reference de Raedt, Dumancic, Manhaeve and Marra2020; Lamb et al. Reference Lamb, d’Avila Garcez, Gori, Prates, Avelar and Vardi2020; Pisano et al. Reference Pisano, Ciatto, Calegari and Omicini2020; Tarau 2021) where LP and neural networks are combined or integrated in several ways following the purpose of engineering more generally intelligent systems capable of coupling the inferential capabilities of LP with the flexible pattern-matching capabilities of neural networks.

Inductive Logic Programming: Inductive Logic Programming (ILP), first coined by Muggleton and de Raedt (Reference Muggleton and de Raedt1994) is a subfield of machine learning that studies how to learn computer programs from data, where both the programs and the data are logic programs. Prolog in particular is typically used for representing background knowledge, examples, and induced theories. This uniformity of representation gives ILP the advantage, compared to other machine learning techniques, that it is easy to include additional information in the learning problem, thus enhancing comprehensibility and intelligibility. Muggleton first implemented ILP in the PROGOL system.

ILP has shown promise in addressing common limitations of the state-of-the-art in machine learning, such as poor generalization, a lack of interpretability, and a need for large amounts of training data. The first two affect quality and usability of results, and the latter affects accessibility and sustainability: the requirements of storing and processing exponentially growing amounts of data already make its processing prohibitive. In this context, ILP shows especial promise as a tool enabling a shift from using hand-crafted background knowledge to learning background knowledge, including learning recursive programs that generalize from few examples. These issues, as well as future promising directions, have been recently surveyed by Cropper et al. (Reference Cropper, Dumančić and Muggleton2020).

Further developing the ideas of ILP to encompass the automated learning of probabilistic logic programs is key to Statistical Relational AI (StaRAI), a successful hybrid field of AI (de Raedt et al. Reference de Raedt, Kersting, Natarajan and Poole2016), for which regular workshops have been held since 2010. Tools based on this paradigm aim to handle complex and large-scale problems involving elaborate relational structures and uncertainty.

Bridges to Established Research Areas

Novel opportunities may then arise by bridging Prolog with other well-established research areas. This is, for instance, what happened with the Multi-Agent System community, where Prolog and LP have been extensively exploited in the last decades as the technological or conceptual basis for tens of agent-oriented technologies (Calegari et al. Reference Calegari, Ciatto, Mascardi and Omicini2021). Similarly, the Prolog language has been proposed within the scope of Distributed Ledger Technologies (a.k.a. Blockchains), by Ciatto et al. (Reference Ciatto, Calegari, Mariani, Denti and Omicini2018), or as a means to provide more declarative sorts of smart contracts, as suggested by Ciatto et al. (Reference Ciatto, Maffi, Mariani, Omicini and Notes2019) and Ciatto et al. (Reference Ciatto, Schumacher, Omicini, Calvaresi and Notes2020). There, LP pursues the goal of making smart contracts declarative, hence easing their adoption, and increasing their expressiveness. More generally, begining with the Prolog implementation of the British Nationality Act, Prolog has been used extensively for applications to computational law and is proabably still the dominant approach. For example, the logic programming language in Oracle Policy Automation ^{Footnote 8} was originally implemented in Prolog.

In data science, several data sources need to be cleaned and combined before applying statistical analysis and machine learning. This preprocessing step is often the most labor intensive phase of a data science project. Prolog, particularly when extended with tabling support, is a suitable tool for data preprocessing. It can transparently access data from different sources without needing to repeatedly import all the data, for example, from a relational database management systems. Subsequently, a view on the data can be established from small composable predicates that can be debugged separately and interactively. These ideas have been explored in SWISH datalab (Bogaard et al. Reference Bogaard, Wielemaker, Hollink and van Ossenbruggen2016) which provides a web front end for cooperative development of both Prolog data preprocessing steps and subsequent statistical analysis using R, and used in applications in Biology using large data (Angelopoulos and Wielemaker Reference Angelopoulos and Wielemaker2019). Other Prologs, such as Yap, include support for dealing with large data sets (Costa Reference Costa2007; Costa and Vaz Reference Costa and Vaz2013).

Summarizing, it might prove very useful for the community to anticipate what features may attract programmers for ends such as improving AI, the Internet, programming languages, or knowledge intensive systems in general.

4.4.1 Fragmentation of the community

A large threat to the future of Prolog as an accessible programming language is further fragmentation of the community. This manifests itself in two dimensions:

User Bases Today, the Prolog language lacks a strong, united presence on the Web, especially when compared to other languages, such as the Python Homepage (Reference Homepage2021), Rust Homepage (Reference Homepage2021), R Homepage (Reference Homepage2021), Clojure Homepage (Reference Homepage2021) or Julia Homepage (Reference Homepage2021). Hence, there is limited exchange between users of Prolog, in particular of different Prolog systems. Only a few shared platforms exist, such as the venerable comp.lang.prolog newsgroup, the Prolog subreddit, or StackOverflow. They have in common that they are not very active and are mostly used for announcements or beginner questions. There are some exceptions, such as the SWI-Prolog discourse forum, hosting active discussions on the implementation, but, again, it is a barrier since it is essentially local to this system. The lack of an overarching presence, thus, lowers Prolog’s visibility, hinders development of shared libraries, and might be an entry barrier for new Prolog users. It may even deter programmers from adapting LP technology due to outdated or wrong information on Wikipedia pages on Prolog or Logic Programming in general, or due to missing FAQs, API documentation, and tutorials.

The current fragmentation of the Prolog community may be seen as a threat to the language standardization effort and, thus, the advancement of Prolog. Compilation of standardization documents takes a very long time and is currently driven by a few volunteers. While only experts can evaluate the impact of changes in the standard on existing Prolog systems, the community may assist such efforts by pinpointing differences between systems, prioritizing features that should be considered next, or by providing test cases. However, the community is hard to reach in a unified way and such contributions are often limited to motivated individuals and remain scarce.

Implementors While implementors of Prolog systems meet at the CICLOPS workshops and other conferences, they do not have a good shared infrastructure to revise syntax, discuss libraries, tools and technical questions, or to offer existing code or tests. Without such workflows and regular discussion of future directions, Prolog systems may further diverge in features, libraries, and possibly even from the ISO standard if no concerted effort is made to find common best solutions. New developers need a forum to ask questions and benefit from lessons learned. Otherwise, implementation work may be duplicated, no common Prolog tooling will be developed, etc.

4.4.2 Lack of strong stewardship

The largest single threat we see for the future compatibility of Prolog systems and attractiveness of the language in the long term is the lack of a strong stewardship. All implementors we were able to reach for comments agree with the need for compatibility, are willing to discuss issues and work on their systems to address them. However, the most lacking resource is time, as compatibility work diverts efforts from research and development.

A dedicated entity, which acts as a steward, calls meetings on a regular basis to ensure progress, and oversees open issues is missing and necessary, but establishing it is not without challenges. Sufficient financial and/or institutional backing to motivate implementors and to fund at least one steward position would be an asset. Additional human resource positions may be needed to address specific aspects, such as interoperability, source code compatibility, and website maintenance.

Two major collective efforts, the ISO process and the Prolog Commons group, have already been established that can be regarded as such entities and persist with varying success:

The ISO Process The ISO working group has the strong mission to provide a robust and concise standard that makes Prolog attractive for the industry, giving it a competitive advantage. The core standard was a huge leap in the right direction, providing a strong basis for compatibility. However, further progress has been rather slow, which may be due to the nature of ISO as well as the voluntary nature of the work of the participants and their aspirations for stability and high-quality work. Unfortunately, only a few of the actual system implementors are currently active in the ISO standardization efforts. Also, the process is complex and may be too slow despite steady progress, since even more and more features and libraries are developed independently.

Prolog Commons The Prolog Commons project started as a series of informal implementor meetings to improve the portability of Prolog code, in a more agile and interactive setting than the ISO process. This impetus pushed many participating systems in converging directions, producing changes in their documentation systems, improved compatibility/emulation layers, and plans for further integrations. The reason that the project has not fully materialized into a common code base is, again, the lack of stewardship, meeting schedules, and deadlines, combined with the available time of the implementors.

4.5.1 Portability of existing features

The differences between the various Prolog implementations, either in the set of features provided (cf. Table 2) or in the way the features work, lead to a code portability problem between Prolog implementations. Circumventing this problem rather than solving it results in fragmenting the community into smaller, noncompatible subgroups. This makes it hard for users to find support and stay interested.

Strong and universally accepted standards for available features may raise interest from programmers and industry. Yet, if some combination of them are missing in many Prolog systems, it will negatively impact the perception of Prolog. One of the nonstandard offers of Prolog is constraint logic programming. Yet, choosing a Prolog system requires certain trade-offs concerning the available features. Many of these features concern performance, such as tabling, efficient coroutining via block annotations, and multiargument indexing. Some programmers may not want to give up what they are used to from other programming languages, like multithreaded, concurrent and distributed programming, standard libraries for formatting and pretty printing, efficient hash map data structures, and universally available data structures such as AVL trees or sets. Finally, some features are needed to embed Prolog as a component in a larger software system, for example, nonblocking IO, interfaces to other programming languages or (de-)serialization support, such as fastwrite/fastread, XML, JSON, YAML.

4.5.2 Improved development tools

An important area of future improvement is in the development tools available for the language. The dynamic nature and complex control of Prolog raises new challenges in the implementation of some of these features, but its clear logical foundations provide an advantage for others. We see a potential and a need for the following improvements to the Prolog tooling ecosystem:

• Increased capabilities in debuggers (e.g., constraint debugging or graphical interaction), performance profiling tools, and testing frameworks. The combination of static and dynamic verification, debugging, and testing of Ciao is relevant here (Hermenegildo et al. Reference Hermenegildo, Puebla, Bueno and Garcia2005; Sanchez-Ordaz et al. Reference Sanchez-Ordaz, Garcia-Contreras, Perez-Carrasco, Morales, Lopez-Garcia and Hermenegildo2021).

• Better experience using interactive shells: Prolog could also profit from being integrated within notebooks such as Jupyter, as has been done in SWISH (Wielemaker et al. Reference Wielemaker, Riguzzi, Kowalski, Lager, Sadri and Calejo2019).

• More regular, user-friendly, and standardized ways of interfacing with other languages. Features that should be accounted for include nondeterminism, convenient and safe data types, and memory management coexistence.

• More capable IDEs, in particular with good refactoring tools, which help the programmer to safely reorder or change the arguments of predicates, rename, or move predicates to other modules, etc., in the line of SICStus’ SPIDER (Carlsson and Mildner Reference Carlsson and Mildner2012). Prolog itself may be used as the GUI programming language in developing the IDE.

• Linters that enforce community-sourced coding guidelines based on, for example, the proposals by Covington et al. (Reference Covington, Bagnara, O’Keefe, Wielemaker and Price2012) and Nogatz et al. (Reference Nogatz, Körner and Krings2019).

• Improved code location facilities, such as Ciao’s Semantic Search (Garcia-Contreras et al. Reference Garcia-Contreras, Morales and Hermenegildo2016).

• Other static program analysis tools, enabling for instance the inspection of dependencies among modules, and the existence of call hierarchies among predicates. Also, dynamic process inspection tools aimed at visualizing call stacks, choice points queues, proof trees, etc. (see also Section 4.5.3, State Inspection).

4.5.3 Application- and domain-specific needs

In this section, we consider a few domains that we think may influence Prolog in the future and try to anticipate future developments that are needed to satisfy their needs.

Parsing The parsing domain has implications both for computing sciences, in that it can be applied to compilers or other program transformations, and for sciences and the arts, in that many kinds of human languages (e.g., written, spoken, or those of molecular biology or music) can be computationally processed for various ends through parsing.

As far as pure parsing is concerned, one can of course easily write top-down recursive descent parsers in Prolog using DCGs. However, encoding deterministic parsing with lookahead requires the careful use of the cut, which is tedious and error-prone. Ideally, the cuts could be automatically generated by standard compiler construction algorithms (Nullable, First, Follow) and a Prolog-specific parser generator. Bottom-up parsers are also easy to write using, for instance, CHR. Another way to improve Prolog’s parsing capabilities is through memoing, which avoids the infinite loops that left-recursive grammars are prone to, thus needing to resort less to the cut, and avoids recomputations of unfinished constituents in the case of alternative analyses where one analysis is subsumed by another. This is done by storing them in a table so they need not be recomputed upon backtrack (e.g., in “Marie Curie discovered Polonium in 1898,” the partial analyses of the verb phrase as just a verb or as a verb plus an object are stored in a table for reuse rather than disappearing upon failure and backtrack). Memoing can be easily implemented in Prolog, for example, through assumptions, as discussed by Christiansen and Dahl (Reference Christiansen and Dahl2018), or through CHR, as discussed by Frühwirth (Reference Frühwirth2009), or using tabling as in XSB Prolog.

NLP and Neural Networks Neural-network approaches to NLP use word embedding strategies to generalize from known facts to plausible ones (e.g., BERT Devlin et al. Reference Devlin, Chang, Lee and Toutanova2019, GPT-3 Floridi and Chiriatti Reference Floridi and Chiriatti2020). They typically train only on form, in that they retrieve those responses that are statistically pertinent, with no regard to meaning. Their results are unstable, since they rely on ever larger and changing internet-mined data. While this approach has achieved noteworthy performance milestones in machine translation, sentence completion, and other standard benchmarking tasks, it offers a priori no way to learn meaning (Bender and Koller Reference Bender and Koller2020) and relies on undocumented, un-retraceable, or otherwise partial (and therefore unaccountable) data, which tends to perpetuate harm without recourse (Birhane Reference Birhane2021). It is also resource-intensive, both computationally and energetically, and prone to spectacular failure (Marcus and Davis Reference Marcus and Davis2020). It seems that overcoming such drawbacks will need inferential programming capabilities, which integrations with deductive reasoning might help achieve. We anticipate that efforts in that direction, which are already happening (Sun et al. Reference Sun, Arnold, Bedrax-Weiss, Pereira and Cohen2020), will be increasingly needed.

Another NLP area which we anticipate will require much attention and that Prolog can be ideal for is that of under-resourced human languages. Very few of the over 7000 languages in existence have at their disposal the computational tools that are needed for their adequate processing. Since texts on the Web are also overwhelmingly in mainstream languages, and the machine learning approaches that are in vogue typically rely on mining massive volumes of text, when these do not exist (or as soon as the existing ones become more protected) we need more logical approaches, such as grammatical inference by grammar transformation.

Problem Solving, Solvers Constraint programming blends nicely within Prolog (see Section 3.3.2), in the form of CLP( $\mathcal{FD}$ ), CLP( $\cal B$ ), CLP( $\cal R$ ), or CLP( $\cal Q$ ), and also in the CHR form, which lets users define constraint solvers for their own domain of interest. However, the binding to SAT, SMT, or ASP solvers is often still quite awkward. In particular, ASP with its Prolog syntax could be made available as a seamless extension to Prolog. Similarly, SAT and SMT solving could also be linked in a seamless way to Prolog facts or clauses. In an ideal world, one could even link various solvers via shared variables and coroutines.

Visualization and GUIs Visualization is nowadays most often performed via the foreign language interface or by exporting data to external tools (e.g., dot text files for GraphViz). While BIM-Prolog (cf. Section 2.10.1) had a declarative graphical toolkit, unfortunately Prolog systems have moved away from this approach. Other communities, however, are discovering the advantages of a “declarative approach” to visualization and user-interface design (e.g., React Gackenheimer and Paul Reference Gackenheimer and Paul2015 in the JavaScript world). Maybe it is time again to implement visualizations or user interfaces within Prolog itself.

State Inspection Prolog 0 already included primitives to programmatically inspect the computation state. These can be useful for example in debugging or in parsing, in order to implement context-sensitive grammars. Current Prologs allow different degrees of state inspection, including for example the classic facilities that enable meta-programming. Such primitives could acquire new relevance under the increasing needs for further transparency and inspectability in AI applications.

4.5.4 Prolog aspects that need joint, public, and earnest discussion

There are a number of issues that would need early discussion in the process of giving a new impetus to Prolog standardization. While we raise questions here, we cannot speak on behalf of the entire community. Thus, we think that a visible (in the sense of commonly-known) platform for public discussion between implementors and users is required. The Prolog language should eventually evolve on results of discussions and needs of (potential) programmers. For some issues we discuss below, several solutions have been offered by the research community. However, the Prolog community has to discuss what features shall be adapted as standard. Further, one might also consider whether purely declarative implementations are preferable or even feasible, since some features, such as assert and retract, do not even have a declarative, logical semantics. The following points are some examples:

Types, Modes, and Other Properties Often, during development, a Prolog program may terminate without finding a solution, get stuck in an infinite loop, backtrack unexpectedly, etc. Often, this sort of situation is due to type errors in the code. Should a type (and mode, etc.) system be part of an improved Prolog, allowing for more powerful static analysis? If so, what should it look like? What would have to be changed for a useful gradual static type system that allows one to progressively add types to existing code? Should more general properties than classical types and modes be supported? Should static types be combined with dynamic checks? With testing? The logic programming community has been pioneering in these areas with research, solutions, and systems well ahead of other languages, but it has not yet seen widespread use. Ciao’s comprehensive approach to this overall topic could shed some light here.

Reactivity A rule in Prolog can be viewed as a part of a definition that defines the predicate in the head of that rule in terms of the predicates in the body of the rule. In contrast, most rules in imperative languages are reactive rules that perform actions to change state, as in the case of condition-action rules in production systems and event-condition-action rules in active database systems. Extensions of logic programming to include reactive rules have been developed in CHR (see Chapter 6 in Frühwirth Reference Frühwirth2009) and in the Logic-based Production System Language LPS (Kowalski and Sadri Reference Kowalski and Sadri2015; DBLP:journals/tplp/WielemakerRKLSC19).

Module System As mentioned before, the second part of the ISO standard regarding modules was universally ignored and most Prolog systems settled for a Quintus-inspired module system. However, the implementations incorporate some deviations to support new features. Rules regarding visibility of operators, predicates, and perhaps atoms should be reconsidered. This is addressed to some extent, for example, in the Ciao and SWI module systems but, again, with some differences, which should however not be too difficult to bridge. Systems support some of the legacy code loading methods such as consult/1 and ensure_loaded/1 for backwards compatibility, but use_module/{1,2} is recommended, specially for large-scale applications. New solutions must address errors and inconsistencies that have already been uncovered by Haemmerlé and Fages (Reference Haemmerlé, Fages and Notes2006) and later by Moura (Reference Moura2009a).

Objects An aspect which is closely tied to the module system is that of integrating logic programming with object-oriented features. This has been an elusive goal but, nevertheless, several effective proposals have been put forward which achieve ways of doing whole-program composition more in line with the Logic Programming paradigm. Monteiro and Porto (Reference Monteiro and Porto1989) present the basic concepts of Contextual Logic Programming while Bugliesi et al. (Reference Bugliesi, Lamma and Mello1994) offers an extensive discussion on this topic. A more advanced design, in which modules (called units) may take parameters and where the context itself becomes a first-class object is provided by GNU Prolog/CX (Abreu and Diaz Reference Abreu and Diaz2003), which appears as both an object-oriented extension and a dynamic program-structuring mechanism. An application of this system is described by Abreu and Nogueira (Reference Abreu and Nogueira2005).

Another example is the O’Ciao model, which implements a source-to-source approach to objects as a conservative extension of the Prolog module system (Pineda and Bueno Reference Pineda and Bueno2002). Logtalk offers a different approach, also based on source-to-source transformations, that adds a separate object-oriented layer on top of many Prolog systems. Thus, it regards objects as a replacement for a module system.

Interfaces Beyond modules, programming in the large can be supported by mechanisms that allow describing and enforcing separation between interfaces and implementations. Such interfaces are typically sets of signatures, specifying types and other properties, to be matched by all implementations, and thus allow stating what a given implementation must meet, and making implementations interchangeable in principle. They should include at least constructs to express the external connections of a module, not only in terms of the predicates it should expose but also the types, modes, and other characteristics of their arguments, and a compiler/interpreter capable of enforcing those interfaces at compile- or loading time. Ciao’s assertion language, preprocessor, and interface definitions offer a possible solution in this area.

Syntactical Support for Data Structures One of Prolog’s strengths is a minimalistic syntax. SWI-Prolog’s syntactic support for strings and dictionaries responds to a demand for interfacing with prevalent protocols and exchange formats, for example, XML and YAML. Other systems have other extensions such as feature terms (Aït-Kaci 1993; Aït-Kaci et al. 1994).

Many questions need to be answered: Should syntactical support for data types such as associative data structures (feature terms) or strings be standardized? Would the current syntax be affected (e.g., a prevalent syntax for maps, "key”: “value", might break DCGs)? What are trade-offs the community is willing to take? Should other containers, such as linear access arrays, sets, and character types, be included? How should unification of variable elements work?

Library Infrastructure and Conditional Code As Moura’s efforts concerning Logtalk (cf. Section) showed, it is possible to support large portable applications across almost all Prolog systems. Yet, a nontrivial amount of conditional code for abstraction libraries is needed to provide support for each new Prolog system. Is the community willing to develop libraries supporting more than a couple of systems? Is a stronger standardized core library required to attract programmer? Is the language that emerges from the portability layer still Prolog?

Macro System Many Prolog systems support the source-to-source transformation of terms and goals, via the so-called term expanders. It is a powerful feature that is not part of the standard and in some cases can be clunky to use and error-prone since term expanders are often not local to a module, they are order dependent and every term or goal, relevant or not, is fed into the transformation predicate. Ciao shows how module locality and priorities can be used in this context. Or should a more lightweight macro system be made available for code transformation?

Functional Programming Influences Curry and Mercury (cf. Section 3.5) are well known for combining the functional and logic programming paradigms. Some Prolog systems such as Ciao have strong support for functional syntax and higher-order. Most Prolog systems provide support for meta-predicates such as call and some derivatives such as maplist, filter, and reduce. Should a notation for lambda expressions be introduced as done in, for example, Ciao’s predicate abstractions?

Standard Test Programs Beyond ISO While test suites for ISO Prolog exist, many features outside the core language are prevalent in a lot of Prolog systems. Unstandardized features, such as modules, constraint programming, or DCGs, are provided by almost all modern Prolog systems, yet implementors rarely share test programs. Obviously, creation of and agreement on tests is challenging, especially since some systems might want to maintain their features as they are. Availability of such shared tests can guarantee that systems behave similarly, allow implementors to test compatibility with other systems, and foster standardization of these features. As a positive example in this line, Logtalk’s Prolog test suite is quite comprehensive, covering not only ISO- and de-facto standard features, but many other tests of predicates and notable features such as modules, threads, constraints, coroutining, Unicode support or unbounded integer arithmetic.