Meta-Programming for Generalized Horn Clause LogicClemens Beckstein1 and Reinhard Stolle2 and Gerhard Tobermann31 Friedrich-Schiller-Universit�at Jena, Fakult�at f�ur Mathematik und Informatik,Institut f�ur Informatik, D-07740 Jena, Germany,Email: beckstein@informatik.uni-jena.de2 University of Colorado at Boulder, Department of Computer Science,Campus Box 430, Boulder, Colorado 80309, USA,Email: stolle@cs.colorado.edu3 Consulting f�ur O�ce und Information Management GmbH,Industriestr. 1{3, D-91074 Herzogenaurach, GermanyEmail: tobergrh@coi.ina.deAbstract. In conventional logic programming systems, control information is expressedby clause and goal order and by purely procedural constructs, e.g., the Prolog cut. Thisapproach destroys the equivalence of declarative and procedural semantics in logic programs.In this paper, we argue that in order to comply with the logic programming paradigm, con-trol information should also be expressed declaratively. A program should be divided intoa logical theory that speci�es the problem to be solved and control information that spec-i�es the strategy of the deduction process. Control information is expressed through metalevel control clauses. These control clauses are evaluated dynamically in order to select thesubgoal that will be resolved next and to select the resolving clause. Program clauses haveguards that allow clause determinism to be expressed. A major design goal for the presentedwork is to keep the declarative and the procedural semantics of logic programs equivalent.The emphasis lies on the precise speci�cation of the introduced meta level constructs.Keywords: Meta-programming, experimental evaluation, intuitionistic logic, system archi-tecture.1 IntroductionAn essential advantage of the systematic design of logic programs is their duality: on the one hand,a logic program is a formulation of a logical theory which is a speci�cation of the problem to besolved; on the other hand, it can be interpreted in a procedural way. The procedural semanticsof a well designed logic program matches its declarative semantics. However, conventional logicprogramming systems hardly support this design goal. For e�ciency reasons, it is common practiceto use purely procedural constructs whose behavior cannot be described in declarative terms atall. According to the paradigm of logic programming, Algorithm = Logic + Control [Kow79], theinformation specifying the problem to be solved is formulated declaratively as a logic program.Henceforth, we will refer to this information as object level information. The execution of theprogram is controlled by a problem-independent inference machine which a priori cannot bein uenced by the programmer. However, e�ciency and termination of the program executioncan (and typically will) depend on the control strategy that is used. Thus, the programmer shouldbe able to control the deduction process. It should be possible to specify control information thatdynamically determines which literal should be resolved next and which clause should be used toresolve it.In conventional systems, control information is expressed implicitly by taking advantage ofthe inference machine's properties, e.g., its depth-�rst-left-right strategy. This approach does notcomply with the goal of expressing all information in a declarative way. The program containsinformation | namely control information | that is not captured by purely logical interpretationof the program. The availability of alogical constructs like the Prolog cut or the Prolog \predi-cates" assert, retract, and if-then-else encourage an imperative style of programming. These

constructs either have no declarative semantics or are assigned declarative semantics that are dif-ferent from their operational semantics. For example, the Prolog cut is assigned the declarativesemantic value true, but its operational semantics might prune a part of the Sldnf tree thatcontains successful derivations. The dualism of the logic program and its logical theory | theequivalence of procedural and declarative semantics | is destroyed.4We strongly believe that all arguments in favor of a declarative formulation of object levelinformation also apply to control information. Logic programs whose control information is ex-pressed declaratively can be interpreted as logical theories. The object level representation of theproblem has to be clearly separated from statements that control the process of searching forsuccessful derivations. The formulation of object level information will then be independent ofe�ciency considerations. E�ciency will only be an issue when (declarative) control informationis formulated. Furthermore, the separation of object level information and control informationenhances the understandability and simpli�es the maintenance of the logic program.In this paper, we introduce declarative language constructs that allow us to express controlover deduction processes in generalized Horn clause theories. From this point on, we will referto information expressed using these constructs as control information and to the correspondinglanguage level as control or meta level. The paper is organized as follows: We start with anintroduction to programming in generalized Horn clause logic. In sections 3 to 5, we show howcontrol information can be expressed declaratively. In section 6, we specify the semantics of theintroduced control predicates and demonstrate the expressive power of the resulting architecture.In section 7, we sketch correctness and completeness results central to our approach. After adiscussion of related work in section 8, we conclude by pointing to several interesting directionsfor future research.2 Logic Programming in RiscRisc (Reason maintenance based Inference System for generalized Horn C lause logic) is a logicprogramming system developed at the University of Erlangen-N�urnberg [Bec88, BT92, Tob94].Its language is that of generalized Horn clause intuitionistic logic (in the following abbreviated asGHCIL | for a discussion of clausal intuitionistic logic see [McC88a, McC88b]).Risc programs are sets of so-called GHCIL clauses. GHCIL clauses are (implicitly) universallyquanti�ed implications of the following form:1. Each de�nite clause is a GHCIL clause.2. If A is an atomic formula and B1; : : : ; Bn are GHCIL clauses (n � 0), then A B1; : : : ; Bnis a GHCIL clause.Hence, the well known Horn clauses build a non-trivial subset of the set of GHCIL clauses.neurotic(P1) (crazy(P1) criticizes(P2; P1); is friend of (P2; P1))is an example of a GHCIL clause which is not a Horn clause. Its informal meaning is:\For all persons P1: P1 is neurotic if P1 gets crazy under the assumption that there is aperson P2 s.t. P2 criticizes P1 and P2 is a friend of P1."There are several distinguished predicates that may occur in GHCIL clauses. One of them isfalsum,a predicate denoting a contradiction. GHCIL clauses that have falsum as their heads specifycontradictory (unwanted) situations,5 e.g.,falsum female(P );male(P ) (1)4 We do not deny that any programming language needs certain procedural elements (e.g., for in-put/output). However, the logic programming paradigm encourages the programmer to avoid a pro-cedural programming style as far as possible.5 In this paper, we will sometimes refer to clauses for falsum as integrity constraints.2

says that no person P can be female and male at the same time.We distinguish between consistent and inconsistent programs. A Risc program P is consistentif P 6j= falsum . Otherwise, we say P is inconsistent . E.g., every Risc program P 0 containing clause(1) and the unit clausesfemale(pascal) and male(pascal)is inconsistent (P 0 j= falsum). Each consistent Risc program has a least Herbrand modelM(P )such that falsum is false w.r.t.M(P ) (cf. [Tob94]).Risc, in contrast to Prolog, does not support negation as failure. In Risc, embedded impli-cations (which we sometimes will also call conditional goals) of the formfalsum q (or more suggestive: not(q))are used to express a constructive version of negation: negation as inconsistency (see [GS86]), i.e.,for every Risc program P , P j= not(q) i� P [ fqg j= falsum holds.The evaluation of Risc queries is done in a way very similar to the way in which an Sldresolution prover evaluates Horn clause queries (for the formal details see [Tob94]). The main loopof the prover consists of the following steps (let G1; : : : ; Gm be the current goal):1. Select a subgoal Gi w.r.t. a computation rule.62. Search for a clause C = (A B1; : : : ; Bn) such that A and Gi can be uni�ed by� = mgu(A;Gi).3. Compute the new current goal (G1; : : : ; B1; : : : ; Bn; : : : ; Gm)�.An Sld prover searches only the logic program for unifying clauses. The Risc prover also looksup clauses in the so-called current context. The current context is a set of unquanti�ed GHCILclauses. In the sequel, this set will be denoted by �. Initially, the current context is empty. Butwhenever in step (1) a goal Gi of the form D H1; : : : ; Hk is selected, the Risc prover1. adds fH1; : : : ; Hkg to the current context,2. tries to prove D (w.r.t. the extended current context), and3. eventually removes fH1; : : : ; Hkg from the current context.Core Risc provides no means for control other than declarations of relevancy of predicates,7parametrizable selection functions, and the usual priorization of clauses by the program's clauseorder. In the rest of this paper, we will denote the sequence representing the clauses from theprogram and the current context � in the order of their priority by F� . In the following sections,we describe the extensions of core Risc with which the Risc programmer declaratively controlsthe way in which GHCIL theories are processed.3 Clause Determinism and Directionality: GuardsAs a �rst step, we add guards to GHCIL clauses and call the resulting clauses Risc clauses. Guardsare Risc's way of expressing clause determinism. A Prolog programmer typically uses cuts forthis task. Guards are also used to specify that certain predicates are used only for the intendeddirection. A Risc clause is a formula of the formA G1; : : : ; Gm : B1; : : : ; Bnif A B1; : : : ; Bn is a GHCIL clause and G1; : : : ; Gm are literals using only a special set of systempredicates.86 In Risc, the computation rule may be speci�ed by the user via a meta program.7 Subgoals that are formulated using relevant predicates are called relevant subgoals. Relevant subgoalsare priorized in a certain way. For details see [Bec88, BT92].8 For m = 0, we write the Risc clause as A B1; : : : ; Bn; if additionally n = 0, we just write A.3

Following a suggestion of Deville [Dev90], we allow the meta predicates var/1 and ground/1 tobe used in guards. As in Prolog, var/1 succeeds if its argument is a currently unbound variable,and ground/1 succeeds if its argument is a ground-instantiated term. Furthermore, we allow themeta predicate ngv/1 which succeeds if the argument is neither an unbound variable nor a groundterm.9 We also allow the type-checking meta predicates integer/1, atom/1, and compound/1, andpredicates for the usual comparison operations.The guards in Risc clauses have no declarative semantics. They are not intended to be used toexpress logical facts about a problem. We provide guards only in order to formulate unavoidableprocedural aspects of the problem to be solved. Therefore, a Risc clauseA G1; : : : ; Gm : B1; : : : ; Bnhas the declarative semantics of the corresponding GHCIL clauseA B1; : : : ; Bn:The operational semantics of guards is informally described as follows. (Details can be found insection 6.) Let A0 be the subgoal that has been selected by the Risc theorem prover and letC = (A G1; : : : ; Gm : B1; : : : ; Bn)be a Risc clause from the current context. Then, C may be used for the next inference only if1. C is a candidate clause for A0, i.e., A0 and A can be uni�ed by � = mgu(A;A0), and2. all guard goals (G1; : : : ; Gm)� succeed.If there is no candidate clause for a selected subgoal, the subgoal fails and initiates backtracking.If there is at least one candidate clause but none of the guards succeed, the system reports acontrol error . The search for the proof of the current query is then aborted because the theoremprover has run into a situation for which the program is not intended. There are clauses thatcould logically imply the current subgoal, but | for control reasons | none of them can be used.It would be completely inappropriate to consider this situation a fail of the current subgoal andinitiate backtracking.Example 1. The relation plus/3: the third argument is the sum of the �rst and the second argument.plus(X;Y; Z) integer(X); integer(Y ); var (Z) : Z is X + Y:plus(X;Y; Z) integer(X); var (Y ); integer(Z) : Y is Z �X:plus(X;Y; Z) var (X); integer(Y ); integer(Z) : X is Z � Y:The query plus(X;Y; 7) leads to a control error. This is more appropriate than a failure whichwould occur if the guards were part of the clause bodies. Control errors indicate unintendedsituations. A failure could be interpreted as: there are no two numbers that sum up to 7.4 Names of Clauses and SubgoalsObject level clauses and subgoals are represented at the control level by ground-instantiated terms.We use structurally descriptive names for object level constructs:{ An n-ary predicate symbol or function symbol of the object language is represented by ann-ary function symbol of the meta language.{ An object level variable is represented by a ground term var(x) where x is a natural number.The structurally descriptive name of a Risc clause C or a subgoal G is written as dCe or dGe,respectively.9 The abbreviation \ngv" comes from neither ground nor variable.4

Example 2. The Risc clause f(X;Y ) var (X) : g(X); h(Y ) is represented by the meta level termf(var(0); var (1)) var (var (0)) : g(var (0)); h(var (1)).The three subgoals of the conjunction f(X;Y ); h(X); g(Y ) get the names f(var(2); var (3)),h(var (2)), and g(var (3)).In the meta language, the programmer can refer to Risc clauses and subgoals by name schemata.A name schema is a meta level term T which refers to all Risc clauses whose (meta level) nameis an instance of T or to all subgoals whose (meta level) name is an instance of T .In addition to their structurally descriptive names, Risc clauses and subgoals have a secondname which is a constant in the meta language. We call this second name the number of a Riscclause or the number of a subgoal.10 We write the number of a Risc clause C or a subgoal L asbCc or bLc, respectively. The programmer can specify the number N of a Risc clause:N : A G1; : : : ; Gm : B1; : : : ; BnRisc clauses that are not given a number by the programmer are assigned a (unique) numberby the system. Control clauses can refer to a Risc clause by the corresponding clause number.The system predicate clause/2 establishes the link between Risc clauses and their numbers. Thesubgoalclause(N; (A G1; : : : ; Gm : B1; : : : ; Bn))succeeds if there is a Risc clause in the current context whose name is an instance of A G1; : : : ; Gm : B1; : : : ; Bn and whose clause number is an instance of N .The numbers of subgoalscannot be speci�ed by the programmer. They are determined by the system. The link betweensubgoals and their numbers is established by the system predicate goal/2. The subgoalgoal (N; (A B1; : : : ; Bn))succeeds if N is the number of a subgoal L of the currently active goal and A B1; : : : ; Bn is aname schema for L.5 Control Predicates and Control ClausesIn order to control subgoal and clause selection, we provide four meta predicates: clauseorder/2,not ready/1, before/2, and hot/1. A clause whose head is built with one of these predicates iscalled a control clause or a control rule. Control clauses have the formpred(A1; : : : ; Am) B1; : : : ; Bnwhere pred is one of the m-ary control predicates and Bi are atoms. Every predicate used in Bimust either be a system predicate or it must be de�ned by the user by a number of de�nite Hornclauses. Thus, the meta language is that of de�nite Horn clauses.Using the control predicate clauseorder/2, the programmer speci�es the order in which candi-date clauses are selected for an attempt to prove the selected subgoal. Candidate clauses that arenot mentioned by control rules using clauseorder/2 are selected afterwards in the standard orderof the program. Clauses with the predicate clauseorder/2 have the formclauseorder (H; [N1; : : : ; Nr]) B1; : : : ; Bn:where r � 1. Here, Ni are numbers of Risc clauses which can be substituted with meta variables.However, if these meta variables are not instantiated with numbers of Risc clauses by the proofof the body B1; : : : ; Bn, the system reports a control error. A clauseorder control clause speci�esthat the Risc clauses belonging to N1; : : : ; Nr must be selected in this order for the next inferencestep if the selected subgoal is an instance of H .10 We introduce these numbers in addition to the structurally descriptive names because, this will simplifythe formulation of constraints for the automatic detection of inconsistent control information.5

Example 3. The two control clausesclauseorder (p(X); [N;M ]) clause(N; (p(Y ) G1 : true)); clause(M; (p(Z) G2 : B2));B2n == true:clauseorder (p(X); [N;M ]) clause(N; (p(Y ) G1 : B1)); clause(M; (p(Z) G2 : B2));B2n == true; contains(B1; q(Y ));not contains(B2; q(Z)):specify the clause order for the resolution of subgoals for the predicate p/1. All unit clauses(clauses whose body is empty) are tried �rst. Then, all clauses whose bodies contain the literalq(X) are tried. Finally, all other clauses are selected. The system predicate contains/2 succeedsif the second argument is a subterm of the �rst argument. The system predicate not contains/2succeeds in exactly the cases in which contains/2 does not succeed.The control predicates before/2, not ready/1, and hot/1 in uence the selection of subgoals. Clausesfor these predicates have the formbefore(L1; L2) B1; : : : ; Bnnot ready(L) B1; : : : ; Bnhot(L) B1; : : : ; Bnwhere L;L1, and L2 are name schemata for subgoals of the goal which is currently considered bythe Risc theorem prover.Clauses for the control predicate before/2 de�ne a partial order on the subgoals of the currentlyactive goal. Only the minimal elements of this order may be selected. Subgoals that can be provento be not ready may not be selected. If the partial order has several minimal elements that areready, control clauses for the control predicate hot/1 might indicate which subgoal ought to beselected. If there are still several equally priorized subgoals, the selection function gets to decide.The selection function's input is the sublist of all subgoals that are ready, hot, and minimalelements of the partial order. If none of the ready minimal elements is hot, the sublist contains allsubgoals that are ready and minimal elements of the partial order.Example 4. The control clausebefore(N1; N2) goal(N1; H1 true); goal(N2; H2 B2); B2n == true:speci�es that conditional subgoals must be selected after all other subgoals.Example 5. The program of Example 1 plus the following three control clausesnot ready(N) goal(N; plus(X;Y; Z) true); var(X); var (Y ):not ready(N) goal(N; plus(X;Y; Z) true); var(X); var (Z):not ready(N) goal(N; plus(X;Y; Z) true); var(Y ); var (Z):Subgoals for the predicate plus/3 are delayed if at least two of the arguments are variables. Thesubgoal plus(X;Y; 7) would, in contrast to Example 1, not necessarily cause a control error.6 Semantics of Control ClausesHenceforth, let PO be the object level logic program and PC the control level logic program. POis a set of Risc clauses. PC is a set of de�nite Horn clauses which may include clauses for thecontrol predicates and clauses for user-de�ned predicates.Control clauses in PC are considered in two situations:1. during the selection of a subgoal of the goal G which is currently considered by the theoremprover, and2. during the selection of the next Risc clause that will be applied to the selected subgoal L.6

In both situations, object level constructs must be available at the control level. In the �rst case,the subgoals of G are made available at the control level by the logic programRg(G) := fgoal (bLic; dLie) j G = L1; : : : ; Lr; (1 � i � r)gVariables that appear in several subgoals Li are represented by the same meta level term (seeExample 2). In the second case, those Risc clauses C that are candidate clauses for the selectedsubgoal and whose guards succeed are made available at the control level by the logic programRcl(L) := fclause(bCc; dCe) j C = A G1; : : : ; Gm : B1; : : : ; Bn;� = mgu(L;A) ^ (G1; : : : ; Gm)� successful.g[ fselected(dLe)gIn contrast to the names of subgoals, object level variables that appear in several clauses are rep-resented by di�erent meta level terms. Since control clauses for clauseorder/2 refer to the subgoalthat has just been selected, Rcl(L) also contains the ground-instantiated unit clause selected(dLe).Variables in L are represented by meta level terms that are di�erent from the meta level termsthat represent variables in candidate clauses.Example 6. Let f(X;Y ) be the selected subgoal. Assume, the clause f(a; Y ) h(Y ) from thecurrent context and the program clause f(X;Y ) g(X;Y ) are the candidate Risc clauses. Then,at the control level, the following clauses are available:clause(1; (f(a; var(0)) true : h(var (0)))):clause(2; (f(var(1); var(2)) true : g(var(1); var (2)))):selected(f(var (3); var(0)) true):6.1 Declarative SemanticsIt is clear that contradictory control information can be speci�ed with the control predicatesintroduced in the previous section. Therefore, if PC represents contradictory control information,this must be re ected by the declarative semantics of the control clauses and the system mustreport a control error. For this purpose, we de�ne a number of logic programs that specify thecorresponding integrity constraints. The logic programs in Figure 1 specify integrity constraintsfor the selection of the subgoal. The logic program in Figure 2 speci�es integrity constraints forthe clause order.The logic program Ib(G) de�nes the predicate gbefore/2 which represents the transitive closureof the binary relation before. The last three clauses of Ib(G) are integrity constraints. The �rstone prohibits re exivity or the relation gbefore. Thus, it is illegal to require that a subgoal hasto be selected before itself. The next two clauses for falsum ensure that control information isonly about subgoals of the currently active goal. The system predicate invalid gnum/1 succeeds ifits argument is a variable or if it is not one of the numbers bL1c; : : : ; bLrc.11 The logic programInr(G) contains two integrity constraints for control clauses for the predicate not ready/1. The�rst constraint states that at least one subgoal of the currently active goal must not be in therelation not ready/1. The second constraint prohibits control statements about subgoals that arenot subgoals of the currently active goal. Finally, the logic program Ih(G) states that only subgoalsof the current goal may be hot.The necessary integrity constraints for the selection of the Risc clause that is applied next formthe logic program in Figure 2. The predicate prefer/2 de�nes which clauses must be selected beforeother clauses according to the priority lists. The last three clauses of Icl(L) are, again, integrityconstraints. The �rst one prohibits re exivity of the relation prefer/2. The last two clauses prohibitcontrol statements about unavailable clauses. The system predicate invalid cnum/1 succeeds if itsargument is a variable or if it is not the number of one of the Risc clauses in Rcl(L).11 The availability of the system predicate invalid gnum/1 does not imply that we need the meta predicatevar/1 at the control level. 7

Logic Program Ib(G):gbefore(L1; L2) before(L1; L2):gbefore(L1; L3) before(L1; L2); gbefore(L2; L3):falsum gbefore(L; L):falsum gbefore(L1; L2); invalid gnum(L1):falsum gbefore(L1; L2); invalid gnum(L2):Logic Program Inr(G):falsum not ready(1); : : : ; not ready(r):falsum not ready(N); invalid gnum(N):Logic Program Ih(G):falsum hot(N); invalid gnum(N):Fig. 1. The logic programs Ib(G), Inr(G), and Ih(G)neighbours in(X;Y; [X;Y jZ]):neighbours in(U;V; [XjY ]) neighbours in(U; V; Y ):clbefore(L1; L2) selected (G);clauseorder (G;ClNumList);neighbours in(L1; L2;ClNumList):prefer(L1; L2) clbefore(L1; L2):prefer(L1; L3) clbefore(L1; L2);prefer(L2; L3):falsum prefer(L;L):falsum prefer(L1; L2); invalid cnum(L1):falsum prefer(L1; L2); invalid cnum(L2):Fig. 2. The logic program Icl(L)Now, we are prepared to de�ne the declarative semantics of control rules. For the selection ofa subgoal of the goal G, we consider the setPgc(G) := PC [ Rg(G) [ Ib(G) [ Inr(G) [ Ih(G)of GHCIL clauses. For the selection of the next Risc clause that will be applied to the selectedsubgoal L, we consider the setPcc(L) := PC [ Rcl(L) [ Icl(L)of GHCIL clauses.12 If Pgc(G) or Pcc(L) is inconsistent, then PC represents contradictory controlinformation for the current situation which is determined by G or L, respectively. Otherwise, theHerbrand model13 of the corresponding set of GHCIL clauses determines which subgoals of Gmust be priorized and in what order Risc clauses must be applied to the selected subgoal L.12 The acronyms \gc" and \cc" indicate \goal control" and \clause control".13 which then exists | see [Tob94] 8

6.2 Operational SemanticsThe operational semantics of PC are described in the algorithms in Figures 3 and 4. The procedureselect-goal determines with respect to PC which subgoal is selected from a conjunction G ofsubgoals. The third step of this procedure evaluates the control clauses for before/2. If the setselect-goal(G):1. Let G have the form L1; : : : ; Lr where r > 0.2. Lg := fn j n = bLic ^ 1 � i � rg.3. If PC [Rg(G) [ Ib(G) inconsistent, then report a control error. Otherwise determinethe minimal elements of the partial order given by before/2:V := f(n;m) j PC [Rg(G) j= before(n;m)g:Lmin := Lg � fm j 9n : (n;m) 2 Vg:4. If PC [Rg(G) [ Inr(G) inconsistent, then report a control error. Otherwisedetermine the set of ready subgoals:Lnr := fn 2 Lmin j PC [Rg(G) j= not ready(n)g:Lr := Lmin � Lnr:5. If PC [Rg(G) [ Ih(G) inconsistent, then report a control error. Otherwise determinethe set of hot subgoals:Lh := fn 2 Lr j PC [Rg(G) j= hot(n)g:6. Is Lh 6= ;?yes: Ls := Lh.no: Ls := Lr.7. Determine the sublist selectable of L1; : : : ; Lr for which8i 2 f1; : : : ; rg : Li 2 selectable i� bLic 2 Lsholds. Return R(selectable).Fig. 3. Selection of a subgoal with respect to PCPC [ Rg(G) [ Ib(G) is inconsistent, we have contradictory control information which causes acontrol error to be reported. Otherwise, the procedure select-goal uses the control clauses tobefore/2 in order to determine the partial order on the set of subgoal numbers, i.e., all atoms forthis predicate that are logical consequence of PC[Rg(G). Then, the minimal elements of this partialorder are determined. The existence of at least one minimal element follows from the consistenceof PC [ Rg(G) [ Ib(G) (the graph given by V cannot be cyclic).The next step of the procedureselect-goal checks whether the clauses for the predicate not ready/1 specify contradictory controlinformation. If this is the case, we report a control error. Otherwise, the procedure determines theset Lr of ready subgoals. In step 5, the set Lh of hot subgoals is computed if the clauses for hot/1make no statement about subgoals that do not appear in the goal G (cf. Figure 1). If Lh is notempty, only one of these hot subgoals may be selected. If Lh = ;, then all elements of Lr may beselected. In step 7, the remaining subgoals are inserted into the list selectable in the same orderas they appear in G. Risc's selection function R determines the selected subgoal from this list.The procedure clause-order (see Figure 4) determines the order in which Risc clauses areapplied to a selected subgoal L. Step 2 computes the sequence candidates which contains all(numbers of) Risc clauses whose head can be uni�ed with the selected subgoal. From this sequence,allRisc clauses whose guards do not succeed are removed. If guarded contains more than one clausenumber, step 4 checks whether the clauses for the predicate clauseorder/2 specify contradictorycontrol information. If this is not the case, the partial order on guarded that is speci�ed byclbefore/2 is computed (cf. Figure 2). Because of the consistency of PC [ Rcl(L) [ Icl(L), the9

clause-order(L):1. Let L be the selected subgoal andlet F� be the sequence of clauses visible w.r.t. �.2. Determine the sequence candidates of numbers of clauses in F� that are candidateclauses for L, such that(a) bA G1; : : : ; Gm : B1; : : : ; Bnc 2 candidates i� there is a substitution � s.t.� = mgu(L;A), and(b) for all clauses C;C0: If C is before C0 in F� , then bCc is before bC0c incandidates.If candidates is empty, return failure.3. Determine the sub-sequence guarded of candidates such thatbA G1; : : : ; Gm : B1; : : : ; Bnc 2 guardedi�9�; �0 : � = mgu(L;A) ^ (G1; : : : ; Gm)��0 successful.If guarded is empty, report a control error.If guarded contains exactly one element, then return guarded .4. If PC [Rcl(L)[ Icl(L) inconsistent, then report a control error. Otherwise, determineV := f(n;m) j PC [Rcl(L) [ Icl(L) j= clbefore(n;m):^ n;m 2 guardedgN := fn j (n;m) 2 V _ (m;n) 2 Vg:5. not mentioned := fn j n 2 guardedg � N .6. Determine the sub-sequence standard of guarded such thatn 2 standard i� n 2 not mentioned7. Let preferred be a topological sort of N w.r.t. the relation V.8. Return the sequence preferred + standard(where + denotes concatenation of sequences).Fig. 4. Selection of a clause with respect to PCgraph given by V is acyclic. Therefore, step 7 �nds a topological sort of N .14 The order in whichRisc clauses (via backtracking) will be used to try to deduct the selected subgoal L is given bythe concatenation of the sequences preferred and standard : �rst, all clauses in guarded that arementioned in clauseorder clauses and then, all other clauses in guarded .The procedures clause-order and select-goal do not completely specify the regime that controlsthe evaluation of the appropriate sets of GHCIL clauses. We decided to have the evaluation ofthese logic programs performed by an Earley theorem prover.15 We did this for two reasons. First,these logic programs contain only de�nite Horn clauses. Second, steps 3, 4, and 5 of the algorithmin Figure 3 and step 4 of the algorithm in Figure 4 must compute all logical consequences of thecorresponding logic program for the various predicates.6.3 ExamplesWe conclude this section with some examples that show the expressive power of the object levelinference system Risc. Using control clauses for the predicate clauseorder/2, we can specify theorder in which clauses are applied.Example 7. Use Risc clauses with n premises before Risc clauses that have m > n premises:clauseorder (p(X; a); [N;M ]) clause(N; (p(Y; a) G1 : B1)); clause(M; (p(Z; a) G2 : B2));length(B1; L1); length(B2; L2); L1 < L2:14 In general, several topological sorts are possible. We do not specify which one will be computed. (See,e.g., [Sto93] for a topological sort \approximating" the program's clause order.)15 For details see, for example, [BK91]. 10

Hence, clauseorder clauses allow us to specify problem-independent search strategies.Example 8. In Prolog, e.g., control information interferes with logical statements in order toachieve an e�cient evaluation of huge sets of unit clauses.grandfather (X;Y ) var (Y ); !; father (X;Z); father (Z; Y ):grandfather (X;Y ) father (Z; Y ); father (X;Z):In Risc we �rst express the logical fact by the clausegrandfather (X;Y ) father (X;Z); father(Z; Y ):and then ensure an e�cient evaluation of the subgoals by the control clausesbefore(L1; L2) goal (L1; father (X;Y ) true); goal (L2; father (Y; Z) true);ground(X); var(Z):before(L2; L1) goal (L1; father (X;Y ) true); goal (L2; father (Y; Z) true);ground(Z); var (X):In order to specify that two subgoals ought to be processed like coroutines, we may use not ready :Example 9. The predicate app3/4 which concatenates three lists:app([]; A;A):app([BjC]; D; [BjE]) app(C;D;E):app3 (F;G;H; I) app(F;G;K); app(K;H; I):The queryapp3 (X; []; [c]; [a; b; c])leads to the computation tree shown in Figure 5. Note the two failing paths and the in�nite path.If we add the control clausenot ready(L) goal(L; app(A;B;C)); var (A); var (C):then subgoals for app/3 are delayed if neither the �rst nor the third argument is instantiated. Thecomputation tree in Figure 6 clearly shows that the two subgoalsapp(X; [c];K); app(K; [c]; [a; b; c])take turns in being processed.As demonstrated in the example, queries that would not terminate without control clauses canterminate if control clauses are used.7 Correctness and Completeness ResultsGeneralized Horn Clause Logic is intuitionistically equivalent to a certain subset of McCarty'sClausal Intuitionistic Logic [McC88a, McC88b]. According to Tobermann [Tob94], the calculus ofgeneralized Horn clauses upon which the prover of Risc is based is logically sound and complete.Since Risc performs depth �rst search, it is combinatorially incomplete in the same way as Pro-log: it cannot e�ectively �nd a proof for a logical consequence of the theory represented by theprogram if its derivation is hidden by an in�nite path in the search tree.The introduction of guards and control rules into generalized Horn clause logic does not a�ectthe soundness of Risc's proof procedure. Neither guards nor control rules can \generate" newsolutions that are not logical consequences of the logic program. Control rules for the selection ofsubgoals also preserve completeness: Tobermann has shown in [Tob94] that the selection functionfor a Risc type prover may perform arbitrary computations. The only condition it has to meet11

app3 (X; []; [c]; [a; b; c])��app(X; []; K); app(K; [c]; [a; b; c])}}{{{{{{ ((PPPPPPPPPapp([]; [c]; [a; b; c]) app(T; []; R); app([HjR]; [c]; [a; b; c])vvnnnnnnnnn ))SSSSSSSSSSSapp([H]; [c]; [a; b; c]) app(T1; []; R1); app([Hj[H1jR1]]; [c]; [a; b; c])uukkkkkkkkkkkk ��:::::app([H;H1]; [c]; [a; b; c])�� . . .app([H1]; [c]; [b; c])��app([]; [c]; [c])��2Fig. 5. Computation tree for Example 9 (without meta control)app3 (X; []; [c]; [a; b; c])��app(X; []; K); app(K; [c]; [a; b; c])��app(X; []; [ajT ]); app(T; [c]; [b; c])��app(T1; []; T ); app(T; [c]; [b; c])��app(T1; []; [bjT2]); app(T2; [c]; [c])��app(T3; []; T2); app(T2; [c]; [c])��app(T3; []; [])��2Fig. 6. Computation tree for Example 9 (with meta control)12

in order to preserve completeness is that it must be a total function that selects one of the cur-rent subgoals. Ordering clauses does not a�ect the logical completeness. However, it does a�ectcombinatorial completeness because the prover might follow an in�nite path before it �nds somelogical consequence of the program. The issue for which the use of the meta predicate clause-order/2 is intended is | in addition to e�ciency considerations | to (dynamically) determine acombinatorially complete clause order. However, this is the responsibility of the programmer.Guards are intended to rule out candidate clauses. Improper use of guards may result in logical(and combinatorial) incompleteness:16Example 10. Consider the following program:p(X) var(X) : true: q(a):p(X) nonvar(X) : q(X): r(b):The query p(b) is reduced to the goal q(b) which fails. However, the declarative semantics of theprogram is(8X : p(X)) ^ (8X : p(X) q(X)) ^ q(a) ^ r(b)Therefore, p(b) is a logical consequence of this program.It is the responsibility of the programmer to use guards in a careful manner that preserves thecompleteness of the theorem prover. We decided to add the guard mechanism to Risc for tworeasons: The presence of evaluating system predicates like is/3 introduces unavoidable proceduralaspects. We want to enable the programmer to \cleanly" handle these aspects. The second reason isthat we are convinced that guards can be generated by the logic programming system itself; eitherfrom the plain logic program, or from explicit speci�cations of the directionality of a predicate assuggested by Deville in [Dev90].8 Related WorkVan Harmelen [vH91] de�nes meta level systems as systems that consist of an object system anda meta or control system. The behavior of the object system is controlled by the meta system.Van Harmelen distinguishes three classes of meta level systems. In object level inference systems ,both expressions in the object language and expressions in the meta language are evaluated bythe object level interpreter. Meta level inference systems17 only have an interpreter on the metalevel; inferences on the object level are simulated by the meta interpreter. The third class ofmeta level systems are mixed level inference systems in which two interpreters take turns inprocessing object level expressions and meta level expressions, respectively. In van Harmelen'sterminology, the system de�ned in this paper is a bilingual object level inference system witha ground representation of object level goals and clauses on the meta level (according to theclassi�cation of [vH91] and [HL89]).Bowen and Kowalski [BK82] present an amalgamated meta level inference system for Sldnfresolution. Yalcinalp [Yal91] shows how to generalize this approach so it can handle cuts; however,she chooses a mono-lingual meta level inference system. Pereira [Per82] also describes a mono-lingual meta level inference system; in his approach, the meta interpreter uses user-de�ned rewriterules with which the current subgoal can be modi�ed.Gallaire and Lasserre suggest meta languages for Prolog-like systems. [GL79] introduces thecontrol predicate metal which allows priorities to be assigned to clauses, and the control predicatemetax which is used to freeze literals or to forbid backtracking. However, the semantics of thesemeta predicates are only vaguely de�ned and much is left to the intuition of the reader. WhereasGallaire and Lasserre are unclear about what language is allowed in the bodies of meta rules and16 Since failures in Risc are interpreted as don't know (Negation as Inconsistency [GS86]) rather than no,this incompleteness is less of a problem than in a Negation as Failure approach.17 Meta level inference systems are a subclass of meta level systems.13

what control regime is employed to prove meta rules, we explicitly allow the full language of de�niteHorn clauses in the bodies of control rules, and we let the proofs of control rules be performedby an Earley theorem prover [BK91]. We also clari�ed that the order in which clauses are usedfor resolution in our system is computed only once for each subgoal because recomputation wouldlead to the same order due to the absence of side e�ects. Risc provides no means for prohibitingbacktracking because we want to preserve the equivalence of declarative and procedural semantics.[GL82] presents the idea of establishing a relationship between clauses and their names. How-ever, the semantics of the clause/2 predicate needed to be speci�ed more precisely. Our controlpredicate clauseorder/2 has some similarity to Gallaire and Lasserre's predicate oporder and itsspecial cases opbefore and opfirst. Again, we de�ned Risc's control predicates more precisely,especially where the scope of variables in control rules is concerned. Whereas Gallaire and Lasserreonly consider the �rst control rule that concerns the current situation and whose body is prov-able, Risc considers all applicable control rules and tries to comply with all of them. If theseapplicable control rules lead to inconsistency, Risc reports a control error. In order to guide theselection of subgoals, Gallaire and Lasserre suggest the meta predicates finish, need, needby, andready. Declaration of relevancy in Risc will do the job of finish. Ideas for the semantics of need,needby, and ready which are vaguely given by Gallaire and Lasserre provided some inspirationfor the exact speci�cation of the predicates before/2, not ready/1 and hot/1 in this paper. Gallaireand Lasserre's work in uenced other publications among which are [DLP84, DFN86, Esh86].Other examples of Prolog-like systems that o�er additional control features are listed byNaish [Nai85]. Mu-Prolog and its successor Nu-Prolog [Nai85] provide the means of waitdeclarations in order to express the allowed directions for the use of predicates.18 Risc o�ers twoways of expressing this kind of information: Guards allow the programmer to specify which clauseout of a number of clauses is the appropriate one to resolve a given literal. Rules using the predicatenot ready/1 can delay a subgoal until its instantiations comply with the allowed directions for theuse of the corresponding predicate. We agree with Naish's view that a control error should bereported if the current goal consists only of delayed subgoals.A similar approach can be found in Parlog [Gre87]: mode declarations de�ne whether pa-rameters are input or output parameters. If no clause is found that provides the needed inputarguments, the goal is suspended. Guards can be found in Parlog as well. However, if there ismore than one clause with successful guards, Parlog commits to one of them arbitrarily (com-mitted choice non-determinism). Risc uses all clauses with successful guards via backtracking. Ifthe guards of all matching clauses fail, Risc reports a control error. Parlog reports a failure inthis case which corresponds to Parlog's di�erent declarative semantics: guards are interpretedas premises of the clause, whereas in Risc the declarative semantics of the guards is given by thetrivial goal true.9 ConclusionWe have introduced declarative language constructs that can be used to control deduction pro-cesses in generalized Horn clause theories. These constructs have been integrated into Risc's logicprogramming language. As opposed to Prolog programs, in Risc programs object level informa-tion and control information is clearly distinguishable. This separation of object level informationand control information greatly simpli�es the development and maintenance of logic programs(one of the core arguments in [GL82, p. 177]). It allows a programmer to change the way a givenobject level theory is processed without having to change the object level theory as well. Thedeclarative nature of the approach also facilitates the formulation of dynamic control decisionsrather than expressing control by stating clauses and premises in a static order. Another impor-tant advantage of our approach is that it enables the system to recognize situations where theuser has inadvertently speci�ed contradictory control information. Whenever such a situation isdetected, our system signals a control error. First experiments with our approach indicate that18 This is also roughly the approach taken in the G�odel language [HL94] which is intended to be thedeclarative successor to Prolog. 14

most of the everyday control problems encountered when writing logic programs can be handlednicely with the constructs provided by Risc.We are currently investigating the computational complexity of our control regime looking foran answer to the question of how much control overhead is justi�able in which control situations.There is no doubt that the cost of a poorly controlled search is much higher than the price of goodcontrol decisions.References[Bec88] Beckstein, C.: Zur Logik der Logik-Programmierung | Ein konstruktiver Ansatz, Band 199 derReihe Informatik Fachberichte. Springer-Verlag, 1988.[BK82] Bowen, K. A.; Kowalski, R. A.: Amalgamating Language and Metalanguage in Logic Program-ming. In Clark, K. L.; T�arnlund, S. A., editors: Logic Programming, pages 153{172. AcademicPress, London, 1982.[BK91] Beckstein, C.; Kim, M.: Generalized Earley Deduction and its Correctness. In Christaller, T.,editor: Proc. GWAI-91, Bonn, pages 1{10. Springer-Verlag, 1991. IFB 285.[BT92] Beckstein, C.; Tobermann, G.: Evolutionary Logic Programming with RISC. In: Proceed-ings of the Post-Conference Workshop on Logic Programming Environments (JICSLP 92,Washington D.C.), pages 16{21, November 1992. available via ftp: faui80.uni-erlangen.de:pub/papers/memos/immd8-92-13.ps.gz.[Dev90] Deville, Y.: Logic Programming: Systematic Program Development. Addison-Wesley, 1990.[DFN86] Devanbu, P.; Freeland, M.; Naqvi, S.: A procedural approach to search control in Prolog. In:Proceedings of the Seventh European Conference in Arti�cial Intelligence ECAI'86, pages 53{57,1986.[DLP84] Dincbas, M.; Le Pape, J. P.: Metacontrol of logic programs in METALOG. In: Proceedings ofthe International Conference on Fifth Generation Computing Systems, pages 361{370, 1984.[Esh86] Eshghi, K.: Meta-Language in Logic Programming. Ph.D. thesis, Imperial College of Scienceand Technology, Department of Computing, 1986.[GL79] Gallaire, H.; Lasserre, C.: Controlling Knowledge Deduction in a Declarative Approach. In:Proc. IJCAI-79, pages 1{6, 1979.[GL82] Gallaire, H.; Lasserre, C.: Metalevel Control for Logic Programs. In Clark, K. L.; T�arnlund,S. A., editors: Logic Programming, pages 173{185. Academic Press, London, 1982.[Gre87] Gregory, S.: Parallel Logic Programming in PARLOG. Addison-Wesley, Wokingham, 1987.[GS86] Gabbay, D. M.; Sergot, M. J.: Negation as Inconsistency I. The Journal of Logic Programming,3(1):1{36, April 1986.[HL89] Hill, P. M.; Lloyd, J. W.: Analysis of Meta-Programs. In Abramson, H.; Rogers, M. H., editors:Workshop on Meta-Programming in Logic Programming, pages 23{51, 1989.[HL94] Hill, P. M.; Lloyd, J. W.: The G�odel Programming Language. MIT-Press, 1994.[Kow79] Kowalski, R. A.: Algorithm = Logic + Control. Communications of the ACM, 22(7), July 1979.[McC88a] McCarty, L. T.: Clausal Intuitionistic Logic I. Fixed-Point Semantics. The Journal of LogicProgramming, 5(1):1{32, March 1988.[McC88b] McCarty, L. T.: Clausal Intuitionistic Logic II. Tableau Proof Procedures. The Journal of LogicProgramming, 5(2):93{132, June 1988.[Nai85] Naish, L.: Negation and Control in PROLOG, volume 238 of LNCS. Springer-Verlag, Berlin,1985.[Per82] Pereira, L. M.: Logic Control with Logic. In: Proc. First International Logic ProgrammingConference, pages 9{18, Marseille, 1982.[Sto93] Stolle, R.: Deklarative Kontrolle in Logik-Programmen. Studienarbeit, IMMD, Universit�atErlangen-N�urnberg, Oktober 1993.[Tob94] Tobermann, G.: Verallgemeinerte Hornklausellogik: vom logischen Kalk�ul zum Logik-Program-miersystem. Dissertation, Universit�at Erlangen-N�urnberg, 1994.[vH91] van Harmelen, F.: Meta-level Inference Systems. Morgan Kaufmann Publishers, 1991.[Yal91] Yalcinalp, U.: Meta-Programming for Knowledge Based Systems in Prolog. Ph.D. thesis, CaseWestern Reserve University, Cleveland, Ohio 44106, August 1991. Technical Report TR 91-141.This article was processed using the LATEX macro package with LLNCS style15