J. LOGIC PROGRAMMING 1993:12:1{199 1
LOGIC PROGRAM SYNTHESIS
YVES DEVILLE AND KUNG-KIU LAU
> This pap er presents an overview and a survey of logic program synthesis.
Logic program synthesis is interpreted here in a broad way; it is concerned
with the following question: given a sp eci cation, howdowe get a logic pro-
gram satisfying the sp eci cation? Logic programming provides a uniquely
nice and uniform framework for program synthesis since the sp eci cation,
the synthesis pro cess and the resulting program can all b e expressed in
logic.
Three main approaches to logic program synthesis by formal metho ds are
describ ed: constructive synthesis, deductivesynthesis and inductive syn-
thesis. Related issues such as correctness and veri cation as well as syn-
thesis by informal metho ds are brie y presented.
Our presentation is made coherentbyemploying a uni ed framework of
terminology and notation, and by using the same running example for all
the approaches covered. This pap er thus intends to provide an assessment
of existing work and a framework for future research in logic program syn-
thesis. <
1. INTRODUCTION
Program synthesis refers to the elab oration of a program in some systematic man-
ner, starting from a sp eci cation, that is a statement describing what the program
should do. A sp eci cation mayhavemany forms. We can distinguish formal sp eci-
cations from informal ones. For the latter, the synthesis pro cess cannot b e totally
formalised and can only b e partially automated. Wethus distinguish b etween syn-
thesis by formal methods and synthesis by informal methods .
Address correspondencetoUnite d'Informatique,Universite Catholique de Louvain, Place Ste
Barb e, 2, B-1348 Louvain-la-Neuve, Belgium.
Address correspondencetoDepartment of Computer Science, UniversityofManchester, Oxford
Road, Manchester M13 9PL, United Kingdom.
THE JOURNAL OF LOGIC PROGRAMMING
c
Elsevier Science Publishing Co., Inc., 1993
655 Avenue of the Americas, New York, NY 10010 0743-1066/93/$3.50
2
Program synthesis in general has b een an active area of research outside logic
programming. See [BGK84,Bal85, Gol86, Bie92], for example, for a presentation
of the ma jor achievements. In the early days of logic programming, logic program
synthesis was one of the rst areas of active research, mainly fo cusing on manual
program derivation. By the middle eighties, however, this work had dwindled
considerably. More recently, it has b ecome an active area of research once again,
this time fo cusing mainly on automated or semi-automated synthesis. In this pap er,
wegive a brief survey of the work to date in logic program synthesis.
Logic program synthesis is concerned with the following:
Given a (non-executable) sp eci cation, how to get an (executable)
logic program satisfying the sp eci cation?
where the notions of \sp eci cation" and \executability" are interpreted broadly.
For tackling this problem, logic programming provides a uniquely uniform frame-
work b ecause the sp eci cation, the synthesis pro cess and the resulting program can
all b e expressed in logic.
There are three main approaches to logic program synthesis by formal metho ds:
1
In the constructive approach, a conjecture based on the sp eci cation is
constructively proved, and from this pro of the sp eci ed program is extracted.
We call this approach constructive synthesis .
A more direct approach is to deduce clauses for the sp eci ed program directly
from the sp eci cation. We shall call this approach deductive synthesis .
Another approach can induce a program from a partial sp eci cation of the
program. The program is a generalisation of the partial sp eci cation. We
shall call this approach inductive synthesis .
This survey covers all the ab ove approaches. Related issues such as correctness
and veri cation, as well as synthesis by informal metho ds will brie y b e presented.
This pap er do es not cover some other synthesis approaches, suchasknowledge-
based synthesis [Smi90], synthesis by insp ection (see [BF82, BGK84]), b ecause very
little work has b een done using these approaches in logic programming.
Thus this survey covers only the program synthesis part of the so-called program
development area. Program developmentisamuch larger area since it also includes
other asp ects such as program analysis (e.g. abstract interpretation, termination)
and program transformation (e.g. fold/unfold, partial evaluation), inter alia (see
related pap ers in this Sp ecial Issue for other asp ects of Program Development).
Indeed for the whole pro cess of program development, we should consider the re-
alistic scenario depicted by the spiral: (informal sp eci cation ! incomplete formal
sp eci cation ! unsatisfactory program ! b etter sp eci cation ! more satisfactory
program, and so on). This scenario shows the development pro cess as a life-cycle,
within which program synthesis enables a transition from sp eci cation to program.
We will not deal with this entire life-cycle in this survey. Rather, we concentrate
on synthesis metho ds. However, the reader should b ear in mind the larger context
of program development.
The distinction b etween deductive program synthesis and program transforma-
tion is rather sub jective and often dep ends on the context of the research. A
1
Also known as the proofs-as-programs approach, after [BC85].
3
p ossible di erence could b e that synthesis starts from some non-executable sp ec-
i cation, which usually means a non-recursive description of the problem, whilst
transformation usually starts from an already executable description. Program
transformation will b e covered by a separate survey in this volume. We shall not
cover other related logic programming topics such as programming environments,
inductive logic programming, and semantics.
Our aim for this survey is to provide a broad, extensive (and hop efully complete)
survey in the eld of logic program synthesis. We shall give a coherent presentation
using a uni ed framework of terminology and notation, and the same running ex-
ample for all the approaches covered. By so doing, we shall attempt to exp ose the
similarities and dissimilarities b etween the di erent approaches, and to evaluate
their resp ective strengths and weaknesses.
Given the space limit, it is not p ossible to describ e all the theoretical background
necessary for a full treatment of the examples, or the theoretical diculties and
unsolved theoretical problems for each metho d. Nevertheless, a basic knowledge of
logic programming will b e sucient to get a precise idea of the synthesis metho ds
presented. However, the reader will need to read the original pap ers for a deep er
understanding.
We hop e this pap er provides an assessment of existing work and a framework
for future research in logic program synthesis.
The pap er is organised as follows. In Section 2 we de ne and explain the basic
concepts. In Sections 3, 4, 5, and 6, we present an account of constructivesyn-
thesis, deductive synthesis, inductivesynthesis and synthesis by informal metho ds
resp ectively.Ineach of these sections, we describ e the approach, show the running
example for this approach, and give a brief overview of existing metho ds using the
approach. Finally, in Section 7, we conclude with an assessment of existing work
and pro er our views on the wayahead.
2. BASIC CONCEPTS
In this section, we rst de ne and describ e basic concepts such as sp eci cations and
programs, and then weintro duce commonly used notions of program correctness,
in the framework of logic programming. Finally,wegiveanoverview of correctness
criteria and veri cation metho ds that have b een prop osed.
2.1. Speci cations and Programs
A sp eci cation can b e formal or informal; a program can b e either a pure logic
program or a program in an existing logic programming language such as Prolog.
An informal sp eci cation describ es what will b e called the intended relation. This
is the relation the programmer/sp eci er has in mind when synthesising a program.
De nition 1. The intendedrelation for a predicate r (of arity n), denoted by
I (r ), is a set (of n-tuples) of ground terms.
Example 2. Apairhl ;l i b elongs to I (incl uded)i l , l are ground lists, and
1 2 1 2
all the elements of l b elong to l .
1 2
4
The intended relation for a predicate r can also b e seen as a sp eci c (Herbrand)
interpretation for the predicate r .
In logic programming, formal sp eci cations are usually expressed in some logic.
Such a sp eci cation will b e called a logic sp eci cation.
De nition 3. A logic speci cation of a predicate r , denoted Spec(r )isasetof
logical formulas involving r .
In the ab ove de nition, the form of the logic formulas de ning a logic sp eci-
cation is delib erately vague, to allow sp eci cations by examples and incomplete
sp eci cations. The logic formulas of a logic sp eci cation Spec(r ) necessarily involve
predicate r , but can also contain other predicates de ned within the sp eci cation,
or de ned elsewhere (primitives or other sp eci cations).
In Example 4, the predicate member is assumed to b e a primitivesuchthat
member (H; L) holds i H is a memb er of list L. In practice, member can b e
sp eci ed in another sp eci cation, or together with the sp eci cation of incl uded.
The second logic sp eci cation in Example 4 is a \sp eci cation by examples".
Example 4.
Spec (incl uded)=f incl uded(L ;L ) ()8X ( member (X; L )
1 1 2 1
) member (X; L )) g
2
Spec (incl uded)=f incl uded([]; [2; 1]) ,
2
incl uded([1; 2]; [1; 3; 2; 1]),
:incl uded([2; 1]; []) g
A (pure) logic program can b e seen as a particular case of a logic sp eci ca-
tion, where the language is restricted to de nite Horn clauses (also called program
clauses). This is called a program b ecause it also has a pro cedural or op erational
semantics (SLD-resolution). Sometimes, normal program clauses are used [Llo87],
allowing negations in the b o dies of the clauses.
De nition 5. A logic program for a predicate r , denoted by Prog(r ), is a set of
program clauses.
A logic program for a predicate r will normally contain clauses with the pred-
icate r in the head. In Example 6 it is assumed that the predicate member and
al l are primitives (with remove al l (H; L; N L) holding i NL is the list L remove
without all the o ccurrences of H ). This restriction amounts to assuming that the
subproblems involved have b een, or will b e correctly implemented. They can thus
b e seen as primitives for Prog(r ). This simpli cation for programs (and for logic
sp eci cations) is made for ease of understanding, and can b e overcome bysimul-
taneously considering Prog(r ) (or Spec(r )) and its subproblems [Dev90]. In the
context of synthesis, such predicates are often included in a background theory .
Example 6.
Prog (incl uded)=f incl uded([];L )
1 2
incl uded([H jT ];L ) member (H; L );
2 2
incl uded(T; L ) g 2
5
Prog (incl uded)=f incl uded([]; [])
2
incl uded(L ; [H jT ]) r emov e al l (H; L ;NL );
1 1 1
r emov e al l (H; T ; N T );
2
incl uded(NL ;NT ) g
1 2
Prog (incl uded)=f incl uded(L ;L ) :q (L ;L )
3 1 2 1 2
q (L ;L ) member (X; L );
1 2 1
:member (X; L ) g
2
Finally, an (executable) Prolog program is a program written in the Prolog
language. The di erence b etween Prolog programs and (pure) logic programs is
that most Prolog programs contain control information and/or side-e ect pro cedure
calls that destroy the corresp ondence b etween the declarative semantics and the
pro cedural one.
Most of the existing synthesis metho ds fo cus on the declarative asp ects of logic
programming, and thus usually pro duce logic programs rather than (executable)
Prolog programs. This is not a weakness of the metho ds, but rather a delib erate
separation of concerns. The transition from a correct logic program to an executable
correct Prolog program usually amounts to the intro duction of suitable control
information [Dev90]. We will not cover this issue in this survey.
2.2. Correctness
Correctness (and veri cation) is complementary to program synthesis. Wehave
to verify that the synthesised program ful lls its sp eci cation, or more generally,
that the synthesis metho d is correct (or sound), that is always pro ducing correct
programs.
Correctness criteria relate the intended relation, the logic sp eci cation and the
logic program, one to another. A logic sp eci cation and a logic program denote
some relation, according to some semantics. We here intro duce correctness criteria
which are parametric with resp ect to the chosen underlying semantics.
De nition 7. Let Spec(r ) b e a logic sp eci cation. The meaning of Spec(r )is
2
the set of ground terms
S (r )=f t j Spec(r ) j= r (t) g
s
where j= denotes the chosen semantics for logic sp eci cations.
s
De nition 8. Let Prog(r ) b e a logic program. The meaning of Prog(r )isthe
set of ground terms
P (r )=f t j Prog(r ) j= r (t) g
p
where j= denotes the chosen semantics for logic programs.
p
The semantics de nes how a logic sp eci cation (program) should b e interpreted.
The meaning of a logic sp eci cation (program) de nes how the predicate r should
be interpreted, according to the sp eci cation (program) and the semantics.
2
We assume an underlying Herbrand universe built out of the sp eci cation language.
6
The chosen semantics for logic sp eci cations and logic programs also involve
interpreting (primitive) predicates not de ned in the sp eci cation or in the pro-
gram { for instance a p ossible approach is to add suitable formulas de ning these
predicates. An example of p ossible semantics for a logic sp eci cation could b e its
classical logical consequences. For a logic program, the semantics could b e de ned
by its least Herbrand mo del, or by the set of mo dels of the completed programs
Comp(P ). We refer the reader to the survey on semantics for a detailed presenta-
tion of semantic issues.
2.2.1. Logic Programs versus Logic Speci cations We can de ne three correct-
ness criteria for logic programs with resp ect to logic sp eci cations.
De nition 9. A logic program Prog(r )ispartial ly correct wrt a logic sp eci ca-
tion S pec(r )i P (r ) S(r ).
Partial correctness requires that the meaning of the program is included in the
meaning of the sp eci cation. In other words, every answer computed by the pro-
gram b elongs to the sp eci cation.
De nition 10. A logic program Prog(r )is complete wrt a logic sp eci cation
Spec(r )i P (r ) S(r ).
Completeness is the converse of partial correctness. It requires that the meaning
of the sp eci cation is included in the meaning of the program. It ensures that every
sp eci ed answer is computed by the program.
De nition 11. A logic program Prog(r )is total ly correct wrt a logic sp eci cation
Spec(r )i P (r )=S (r ).
Total correctness is thus the combination of partial correctness and completeness.
Note that total correctness do es not necessarily imply, from a pro cedural p ointof
view, that all SLD-derivations for a given query are nite. By the completeness
of SLD-resolution, each correct answer corresp onds with at least one nite SLD-
derivation.
2.2.2. Logic Speci cations versus IntendedRelations The usual correctness cri-
terion for logic sp eci cations with resp ect to intended relations is the following:
De nition 12. A logic sp eci cation Spec(r )istotal ly correct wrt an intended
relation I (r )i S (r )=I (r ).
Total correctness here can b e decomp osed into partial correctness (also called
consistency here) (S (r ) I(r )) and completeness (S (r ) I(r )). In program syn-
thesis one usually assumes the consistency of the sp eci cation, but not its com-
pleteness. Some inductivesynthesis metho ds explicitly consider incomplete sp eci -
cations (e.g. sp eci cation by examples). For instance, S pec (incl uded) is consistent
2
with I (incl uded), but not complete.
7
2.2.3. Logic Programs versus IntendedRelations Similarly, the usual correctness
criterion for logic programs with resp ect to intended relations is the following:
De nition 13. A logic program Prog(r )istotal ly correct wrt an intended rela-
tion I (r )i P (r )=I (r ).
Total correctness here can also b e decomp osed into partial correctness (P (r ) I(r ))
and completeness (P (r ) I(r )). When the intended relation is informal, sucha
criterion cannot b e established either formally or automatically.However, since
the intended relation is a mathematical one, the correctness criterion can b e estab-
lished by mathematically rigorous, although not formal, metho ds. Such correctness
criteria can thus b e used to guide the synthesis pro cess, esp ecially when incomplete
logic sp eci cations are considered.
Similarly, one could also de ne equivalence criteria b etween logic sp eci cations,
or b etween logic programs. Equivalence could then b e decomp osed into sp ecialisa-
tion and generalisation.
When negations are allowed in the logic programs and in the queries, the cor-
rectness criteria (and the meaning of programs) are usually strengthened. For
instance, b esides having P (r )=S (r ), one may also require some equivalence b e-
tween the negative atoms in the meaning of the program, and the negativeatoms
in the meaning of the sp eci cation.
Whereas veri cation of a program proves its correctness, testing a program can
show its incorrectness. Testing a program can detect di erences (if any) b etween the
executable program and the sp eci cation. To ols for debugging can provide some
help to lo cate where the problems are. Declarative debugging aims at detecting
inconsistencies b etween the logic program (i.e. its declarative meaning) and the
sp eci cation. See the survey on programming environments for a developmentof
this sub ject.
2.3. Overview of Correctness Literature
Most of the literature on correctness could b e describ ed in terms of the ab ove
framework. Dep ending on the sp eci cation language, the form of the logic programs
(with or without negations), and the chosen semantics, various approaches can
b e taken. For de nite programs, the underlying semantics is usually the least
Herbrand mo del (or something equivalent). We will not give a precise accountof
each piece of existing work. The reader is referred to the cited references for a
detailed presentation.
A rst formulation of correctness criteria app eared in [CT77]. This has b een
systematised and extended in [Cla79] (see also [Cla81, CS77]). The programs con-
sidered here are de nite programs. Partial correctness and completeness include the
idea of preconditions on the input. A termination criterion is also prop osed. Var-
ious veri cation metho ds are describ ed: consequence veri cation, computational
induction, and structural induction.
Hogger's work [Hog78, Hog81,Hog84] is also based on de nite programs. He
prop oses two families of criteria: the rst one relating the declarativesemantics of
the logic programs to the logic sp eci cation, and the second one relating the pro-
cedural semantics of the logic program to the logic sp eci cation. He also describ es
8
veri cation metho ds based on transformation and derivation rules.
A similar approach is prop osed in [BC89, BCD90] which discusses veri ca-
tion metho ds and program equivalence. Program equivalence is also treated in
[Mah88, Lev91a, Lev91b]. Notice that Lever considers programs with negations.
In [GLM92], equivalence captures some observational b ehaviour (i.e. computation)
of programs. Generalisation of programs, called extensions, are prop osed in [PS90]
in a framework for program development.
In [Dev90], correctness criteria relate intended relations to logic programs with
p ossible negations. A rst set of criteria relates the intended relation to the declar-
ativesemantics of the (completion of the) logic program. A second set of criteria
relates the intended relation to the sequence of computed answer substitutions of the
Prolog programs (derived from the logic program). These criteria are used within
a metho dology for constructing programs, rather than for verifying programs. The
metho dology also addresses the problem of typ es in correctness criteria. Typ e prob-
lems in correctness criteria and in veri cation are also handled in [Nai87,Nai93].
In [CD88, DF88, DF89], correctness criteria and veri cation metho ds based on
pro of trees are prop osed for de nite programs. Programs with negations are also
treated in [FD92a].
Other veri cation metho ds are prop osed in [Kan86, KF86, KS86, KK88]. How-
ever, the sp eci cation language is here restricted.
In [Bal78],averi cation technique based on a Hoare-like inference rule is pro-
p osed for verifying the partial correctness and the completeness of a de nite pro-
gram. A similar approach is describ ed in [CM91]. Another veri cation metho d
based on annotations and pro cedural semantics, is presented in [DM87]
Correctness criteria have also b een prop osed in the framework of InductiveLogic
Programming. (ILP). In this framework, the logic sp eci cation is a set of p ositive
+
examples (denoted by S pec (r )), and p ossibly a set of negative examples (denoted