The denotational semantics of Horn clauses as a production system

Proceedings of the 2015 Workshop on Partial Evaluation and Program Manipulation, 2015

We present a method for specialising the constraints in constrained Horn clauses with respect to a goal. We use abstract interpretation to compute a model of a query-answer transformation of a given set of clauses and a goal. The effect is to propagate the constraints from the goal top-down and propagate answer constraints bottomup. Our approach does not unfold the clauses at all; we use the constraints from the model to compute a specialised version of each clause in the program. The approach is independent of the abstract domain and the constraints theory underlying the clauses. Experimental results on verification problems show that this is an effective transformation, both in our own verification tools (convex polyhedra analyser) and as a pre-processor to other Horn clause verification tools.

2012

These notes are designed to accompany 8-10 lectures on denotational semantics for Part II of the Cambridge University Computer Science Tripos. Some of the material of this course (roughly, the first half) used to form part of courses on semantics of programming languages for Parts IB/II. The Part IB course on Semantics of Programming Languages is a prerequisite. Tripos questions Of the many past Tripos questions on programming language semantics, here are those which are relevant to the current course and predate those available from the Lab webpage-all denotational semantics questions available from the Lab webpage are relevant.

Preprint, 2019

The paper is devoted to showing how to systematically design a programming language in “reverse order”, i.e. from denotations to syntax. This construction is developed in an algebraic framework consisting of three many-sorted algebras: of denotations, of an abstract syntax and of a concrete syntax. These algebras are constructed in such a way that there is a unique homomorphism from concrete syntax to denotations, which constitutes the denotational semantics of the language. Besides its algebraic framework, the model is set-theoretic, i.e. the denotational domains are just sets, rather than Scott’s reflexive domains. The method is illustrated by a layer-by-layer development of a virtual language Lingua: an applicative layer, an imperative layer (with recursive procedures) and an SQL layer where Lingua is regarded as an API (Application Programming Interface) for an SQL engine. The latter is given a denotational semantics as well. The langue is equipped with a strong typing mechanism which covers basic types (numbers, Booleans, etc.), lists, arrays, record and their arbitrary combinations plus SQL-like types: rows, tables and databases. The model of types includes SQL integrity constraints. The described model is further developed in a preprint book available on my profile: “A Denotational Engineering of Programming Languages”.

1994

In this paper, we introduce logical reflection as a principled way to empower the representation and reasoning capabilities of logic programming systems. In particular, reflection principles take the role of axiom schemata of a particular form that, once added to a given logic program (the basic theory, or the initial axioms), enlarge the set of consequences sanctioned by those initial axioms.

Journal of Automated Reasoning, 1994

We define a class of function-free rule-based production system (PS) programs that exhibit non-deterministic and/or causal behavior. We develop a fixpoint semantics and an equivalent declarative semantics for these programs. The criterion to recognize the class of non-deterministic causal (NDC) PS programs is based upon extending and relaxing the concept of stratification, to partition the rules of the program. Unlike strict stratification, this relaxed stratification criterion allows a more flexible partitioning of the rules and admits programs whose execution is non-deterministic or causal or both. The fixpoint semantics is based upon a monotonic fixpoint operator which guarantees that the execution of the program will terminate. Each fixpoint corresponds to a minimal database of answers for the NDC PS program. Since the execution of the program is non-deterministic, several fixpoints may be obtained. To obtain a declarative meaning for the PS program, we associate a normal logic program PS with each NDC PS program. We use the generalized disjunctive well-founded semantics to provide a meaning to the normal logic program PS. Through these semantics, a well-founded state is associated with PS and a set of possible extensions, each of which are minimal models for the well-founded state, are obtained. We show that the fixpoint semantics for the NDC PS programs is sound and complete with respect to the declarative semantics for the corresponding normal logic program PS. satisfied if the relations contain instantiated tuples corresponding to each of the positive literals and if the relations do not contain tuples corresponding to the negative literals. Rules are (non-deterministically) selected for execution and they update the database. Depending on the action in the head of the selected rule, the relations are updated. New facts are asserted by the a-production rules or existing facts are retracted by the r-production rules. This process continues until a fixpoint is reached. 2.1. Problems in Executing PS Programs There are several problems that may arise when executing a set of production rules. If we interpret the assert and retract actions in a straightforward manner by inserting and deleting tuples from the corresponding relations, then there is a possibility that the execution of the program may not terminate and the relations may be updated indefinitely. The second problem is that when there is more than one execution schedule, the execution may not be minimal. The database produced by one schedule may be a subset of the database produced by a different schedule. We present some example programs that highlight these problems. Example 1 Consider the program with relations Employee, GoodWorker, Manager and Unfriendly, where the initial database has the tuples, {Employee(Mike). GoodWorker(Mike).}, and with the following set of production rules: p 1 : Employee(X), GoodWorker(X) → assert Manager(X) p 2 : Employee(X), ¬ HasOffice(X) → assert Unfriendly(X) p 3 : Manager(X), Unfriendly(X) → retract Manager(X) The first rule promotes employees who are good workers to managers, while the second rule asserts the fact that employees who do not have offices become unfriendly. Finally the third rule rescinds the promotion of managers who are unfriendly. Given this initial database and set of rules, the rules will execute until a fixpoint is reached and the database can no longer be updated. Rules p 1 , and p 2 will execute (in any order) and the tuples Manager(Mike) and Unfriendly(Mike) will be added to the database. Next, the rule p 3 executes and the tuple Manager(Mike) will be deleted from the the database. Subsequently, p 1 and p 3 will execute, first inserting the tuple Manager(Mike) and then deleting this tuple. Processing of these two rules could continue indefinitely, alternately inserting and deleting the tuple Manager(Mike) from the Manager relation, and the program may not terminate. Example 2 This is an example where the rules produce different databases, due to differences in selecting and executing the rules. The corresponding executions are not always minimal. We use the term minimal here informally, to mean that the database resulting from the asserts and retracts of the executed rules, produced by one execution