From the hub
I want to announce that library(ffi) is now available on the master branch of Scryer Prolog. The purpose of this library is be able to call native code via a C ABI. Note that FFI is just one way to communicate with the outside world in Scryer Prolog: sockets, files, pipes or the HTTP libraries are also good options depending on the task and they're safer. This library is based on libffi
PostgreSQL is probably one of the most advanced databases in the relational world. Let's see how can we access it from Scryer Prolog.
Multi-core and highly-connected architectures have become ubiquitous, and this has brought renewed interest in language-based approaches to the exploitation of parallelism. Since its inception, logic programming has been recognized as a programming paradigm with great potential for automated exploitation of parallelism. The comprehensive survey of the first twenty years of research in parallel logic programming, published in 2001, has served since as a fundamental reference to researchers and developers. The contents are quite valid today, but at the same time the field has continued evolving at a fast pace in the years that have followed. Many of these achievements and ongoing research have been driven by the rapid pace of technological innovation, that has led to advances such as very large clusters, the wide diffusion of multi-core processors, the game-changing role of general-purpose graphic processing units, and the ubiquitous adoption of cloud computing. This has been paralleled by significant advances within logic programming, such as tabling, more powerful static analysis and verification, the rapid growth of Answer Set Programming, and in general, more mature implementations and systems. This survey provides a review of the research in parallel logic programming covering the period since 2001, thus providing a natural continuation of the previous survey. The goal of the survey is to serve not only as a reference for researchers and developers of logic programming systems, but also as engaging reading for anyone interested in logic and as a useful source for researchers in parallel systems outside logic programming.
Authors: Agostino Dovier, Andrea Formisano, Gopal Gupta, Manuel V. Hermenegildo, Enrico Pontelli, Ricardo Rocha
A longstanding collaboration with @triska, applying Prolog to the specification and analysis of oncology dose-escalation trial designs, has yielded some interesting progress that I'd like to share. It seems to me that the current thrust of this work employs Prolog — and indeed some new techniques like if_/3 (Neumerkel & Kral 2017) — in a manner that is somehow essential to our successful attack on certain problems in this field. As such, I think our collaboration reflects in some interesting ways on Prolog itself. I'll try to get across the main gist of the application without belaboring the details. The work I'll describe here is contained in this self-contained file from the precautionary package. Author: David C. Norris
This article aims at integrating and applying the main lessons learned in the process of evolution of Prolog. It is structured into three major parts. Firstly, we overview the evolution of Prolog systems and the community approximately up to the ISO standard, considering both the main historic developments and the motivations behind several Prolog implementations, as well as other logic programming languages influenced by Prolog. Then, we discuss the Prolog implementations that are most active after the appearance of the standard: their visions, goals, commonalities, and incompatibilities. Finally, we perform a SWOT analysis in order to better identify the potential of Prolog, and propose future directions along which Prolog might continue to add useful features, interfaces, libraries, and tools, while at the same time improving compatibility between. Authors: Philipp Körner, Michael Leuschel, João Barbosa, Vítor Santos Costa, Verónica Dahl, Manuel V. Hermenegildo, Jose F. Morales, Jan Wielemaker, Daniel Diaz, Salvador Abreu, Giovanni Ciatto
Prolog modules are objects. This statement may surprise you. From past experience, it will also annoy some Prolog practitioners. It is not the case that the creators of Prolog module systems intended to create an object-oriented extension to Prolog. But what modules are is a function of their characteristics, not a function of their design.
Logtalk inherits but also extends and improves Prolog predicate semantics to provide clear and uniform closed world semantics, support protocols, provide consistent meta-predicate semantics, prevent misusing of multifile predicates, and prevent a number of hacks based on predicate directives that would break encapsulation. This post discusses...