Pengines: Web Logic Programming Made Easy

When developing a (web) interface for a deductive database, functionality required by the client is provided by means of HTTP handlers that wrap the logical data access predicates. These handlers are responsible for converting between client and server data representations and typically include options for paginating results. Designing the web accessible API is difficult because it is hard to predict the exact requirements of clients. Pengines changes this picture. The client provides a Prolog program that selects the required data by accessing the logical API of the server. The pengine infrastructure provides general mechanisms for converting Prolog data and handling Prolog non-determinism. The Pengines library is small (2000 lines Prolog, 150 lines JavaScript). It greatly simplifies defining an AJAX based client for a Prolog program and provides non-deterministic RPC between Prolog processes as well as interaction with Prolog engines similar to Paul Tarau's engines. Pengines are available as a standard package for SWI-Prolog 7.Comment: To appear in Theory and Practice of Logic Programmin

dbProlog: a Prolog/relational database interface

dbProlog is a prototype system that provides a C-Prolog user access to data in an external relational database via both loose and tight coupling. To the application programmer, dbProlog is a group of six built-in Prolog predicates that effect communication between a C-Prolog process and a database management system process. Prolog application program statements may be written using the six predicates to make the interface transparent to an end-user. The system is based on a driver process that must be customized to the interfaced DBMS and whose primary function is the translation of requests and replies between C-Prolog and the DBMS. dbProlog supports Prolog\u27s depth-first search on database retrievals by producing the next record when the retrieval predicate is encountered upon backtracking. dbProlog also supports multiple active database retrievals, as may be required by a Prolog rule that references two or more database retrievals, or by a recursive rule

A Hierarchical Database Model for a Logic Programming Language

This paper presents an extended Clausal Database Model for a logic programming language. Instead of being restricted to one global database, as is the case with Prolog, we allow segmentation of the database into database units which are linked together into a semi-lattice. Each database unit defines a database view which includes clauses which have been asserted into that unit as well as clauses inherited from its ancestors higher in the lattice structure. This model supports arbitrary retraction. Retracting a clause in a database unit effectively blocks its inheritance for that unit and all of its descendants. Motivations for using this model are given. We also discuss the implementation of a Prolog meta-interpreter that uses this model. (hereafter referred to as (Phd) or Prolog Hierarchical Database) This meta-interpreter is in the spirit of Prolog and therefore has a version of assert, retract and cut

Bridging the Gap between Object-oriented and Logic Programming

A description is given of an interface that was developed between Loops and Xerox Quintus Prolog. Loops is an extension to the Xerox AI environment to support object-oriented programming; Xerox Quintus Prolog is a version of Prolog that runs on Xerox Lisp machines. Such a bridge enables all the support tools of both environments to be accessed, and degradation of performance that occurs when one language is implemented top of another is avoided. The interface has three layers. At the lowest level, a set of Prolog predicates gives the Prolog programmer access to Loops objects. This lowest level is the bridge from Prolog to Loops. At the next level, programming tools in the Loops environment let object methods be defined in Prolog. At the highest level, the Prolog programmer can treat Prolog clauses as Loops objects that can be manipulated outside the Prolog database. Each layer can be used independently

Extending the logical update view with transaction support

Since the database update view was standardised in the Prolog ISO standard, the so called logical update view is available in all actively maintained Prolog systems. While this update view provided a well defined update semantics and allows for efficient handling of dynamic code, it does not help in maintaining consistency of the dynamic database. With the introduction of multiple threads and deployment of Prolog in continuously running server applications, consistency of the dynamic database becomes important. In this article, we propose an extension to the generation-based implementation of the logical update view that supports transactions. Generation-based transactions have been implemented according to this description in the SWI-Prolog RDF store. The aim of this paper is to motivate transactions, outline an implementation and generate discussion on the desirable semantics and interface prior to implementation.Comment: Appeared in CICLOPS 2012. 9 Pages, 0 Figure

An extensible web interface for databases and its application to storing biochemical data

This paper presents a generic web-based database interface implemented in Prolog. We discuss the advantages of the implementation platform and demonstrate the system's applicability in providing access to integrated biochemical data. Our system exploits two libraries of SWI-Prolog to create a schema-transparent interface within a relational setting. As is expected in declarative programming, the interface was written with minimal programming effort due to the high level of the language and its suitability to the task. We highlight two of Prolog's features that are well suited to the task at hand: term representation of structured documents and relational nature of Prolog which facilitates transparent integration of relational databases. Although we developed the system for accessing in-house biochemical and genomic data the interface is generic and provides a number of extensible features. We describe some of these features with references to our research databases. Finally we outline an in-house library that facilitates interaction between Prolog and the R statistical package. We describe how it has been employed in the present context to store output from statistical analysis on to the database.Comment: Online proceedings of the Joint Workshop on Implementation of Constraint Logic Programming Systems and Logic-based Methods in Programming Environments (CICLOPS-WLPE 2010), Edinburgh, Scotland, U.K., July 15, 201

Operational and denotational semantics of prolog

AbstractA Vienna Definition Language operational semantics of PROLOG, which includes the cut, the database, and the extra-logical operations, is presented. This semantics serves as the basis for deriving a denotational-continuation-style semantics of PROLOG through a systematic transformation of the operational semantics by a method described by Berry