ly, this program guesses nondeterministically the correct permutation via permutation(Xs,Ys), and ordered checks that the permutation is actually ordered. Operationally, the behavior is as follows. A query involving sort is reduced to a query involving permutation and ordered. A failure-driven loop ensues. A permutation of the list is generated by permutation and tested by ordered. If the permuted list is not ordered, the execution backtracks to the permutation goal, which generates another permutation to be tested. Eventually an ordered permutation is generated and the computation terminates. Permutation sort is a highly inefficient sorting algorithm, requiring time super-exponential in the size of the list to be sorted. Pushing the tester into the generator, however, leads to a reasonable algorithm. The generator for permutation sort, permutation, selects an arbitrary element and recursively permutes the rest of the list. The tester, ordered, verifies that the first two elements of the permutation are in order, then recursively checks the rest. If we view the combined recursive permutation and ordered goals as a recursive sorting process, we have the basis for insertion sort, Program 3.21. To sort a list, sort the tail of the list and insert the head of the list into its correct place in the order. The arbitrary selection of an element has been replaced by choosing the first element. Another example of the advantage of intertwining generating and testing can be seen with programs solving the N queens problem. The N queens problem requires the placement of N pieces on an Nby-N rectangular board so that no two pieces are on the same line: horizontal, vertical, or diagonal. The original formulation called for 8 queens to be placed on a chessboard, and the criterion of not being on the same line corresponds to two queens not attacking each other under the rules of chess. Hence the problem's name. 253 Nondeterministic Programming

The art of Prolog

In this chapter we will present the basic concepts of term rewriting that are needed in this book. More details on term rewriting, its applications, and related subjects can be found in the textbook of Baader and Nipkow [BN98]. Readers versed in German are also referred to the textbooks of Avenhaus [Ave95], Bundgen [Bun98], and Drosten [Dro89]. Moreover, there are several survey articles [HO80, DJ90, Klo92, Pla93] that can also be consulted.

Term Rewriting Systems

We survey here various approaches which were proposed to incorporate negation in logic programs. We concentrate on the proof-theoretic and model-theoretic issues and the relationships between them.

/pdf/logic-programming-and-negation-a-survey-13kolvgnfa.pdf

Logic Programming and Negation: A Survey.

We introduce Mercury, a new purely declarative logic programming language designed to provide the support that groups of application programmers need when building large programs. Mercury's strong type, mode, and determinism systems improve program reliability by catching many errors at compile time. We present a new and relatively simple execution model that takes advantage of the information these systems provide, yielding very efficient code. The Mercury compiler uses this execution model to generate portable C code. Our benchmarking shows that the code generated by our implementation is significantly faster than the code generated by mature optimizing implementations of other logic programming languages.

The execution algorithm of mercury, an efficient purely declarative logic programming language

There are numerous papers concerned with the compile-time derivation of certain run-time properties of logic programs, e.g. mode inferencing, type checking, type synthesis, and properties relevant for and -parallel execution. Most approaches have little in common, they are developed in an ad hoc way, and their correctness is not always obvious. We develop a general framework which is suited to develop complex applications and to prove their correctness. All states which are possible at run time can be represented by an infinite set of proof trees ( and trees, SLD derivations). The core idea of our approach is to represent this infinite set of and trees by a finite abstract and-or graph. We present a generic abstract interpretation procedure for the construction of such an abstract and-or graph and formulate conditions which allow us to construct a correct one in finite time.

A practical framework for the abstract interpretation of logic programs

diagnosis searches for incorrectness and incompleteness errors as de ned in Section 3.2, using the su cient conditions given in Table 2. The semantic operator SP is replaced by S P , in a similar way to abstract interpretation. Unlike abstract interpretation, no xpoint computation is needed and lfp(S P ) is not computed. Two di erent kind of observables are considered in [CLMV96a]. Complete observables provide stronger results but are often not practical because the speci cation of the intended semantics I is in nite and diagnosis would not terminate. Such complete observables correspond to the precise abstract operators of Section 5.1. The second kind of observables considered in [CLMV96a] are called approximate observables and their corresponding operator S P is correct but not precise (as is usually the case in abstract interpretation). 5.3 Validation using Abstract Interpretation Abstract diagnosis localizes suspected program constructs following the diagnosis by proof principle. The proof attempt may succeed in which case the program satis es the requirement I (expressed as I ), and abstract diagnosis works as validation. An alternative way of validation is to compute abstract approximations [[P ]] of the actual semantics of the program [[P ]] and then use the de nitions given in Table 1 instead of the su cient conditions of Table 2 (on which abstract diagnosis is based). This is reasonable if one considers that usually program analyses are performed in any case to use the information inferred for optimizing the code of the program. For now, we assume that the program speci cation is given as a semantic value I 2 D . Comparison between actual and intended semantics of the program should be done in the same domain. Thus, for comparison we need in principle ([[P ]]). However, using abstract interpretation, we instead compute [[P ]] , which is an approximation of ([[P ]]), and can be compared with I . We will use the notation [[P ]] + to represent that [[P ]] ([[P ]]). [[P ]] indicates that [[P ]] ([[P ]]). Table 5 gives su cient conditions for correctness and completeness w.r.t. I which can be used when [[P ]] is approximated. Property De nition Su cient condition P is partially correct w.r.t. I ([[P ]]) I [[P ]] + I P is complete w.r.t. I I ([[P ]]) I [[P ]] P is incorrect w.r.t. I ([[P ]]) 6 I [[P ]] 6 I , or [[P ]] + \ I = ^ [[P ]] 6= P is incomplete w.r.t. I I 6 ([[P ]]) I 6 [[P ]] + Table 5: Validation problems using approximations The following conclusions can be drawn from Table 5. Analyses which use a Galois insertion ( +; +), and thus over-approximate the actual semantics (i.e., those denoted as [[P ]] +) are specially suited for proving partial correctness and incompleteness with respect to the abstract speci cation I . It will also be sometimes possible to prove incorrectness in the extreme case in which the semantics inferred by the program is incompatible with the abstract speci cation, i.e., when [[P ]] + \I = . Note that it will only be possible to prove completeness if the abstraction is precise. According to Table 5 only [[P ]] can be used at this end, and in the case we are discussing [[P ]] + holds. Thus, the only possibility is that the abstraction is precise. On the other hand, if a reversed Galois insertion is used ( ; ), and then analysis underapproximates the actual semantics (the case denoted [[P ]] ), it will be possible to prove completeness and incorrectness. Partial correctness and incompleteness can only be proved if the analysis is precise. Note that the results obtained for direct Galois insertions ( +; +) are in essence equivalent to the ones presented for abstract diagnosis [CLMV96a] for approximate observables. In the case 10 of precise abstractions, also completeness may be derivable, and this corresponds to the complete observables of [CLMV96a]. Example 5.2 If the abstract interpretation tells that in [[P ]] + the type of a predicate p with just one argument position is intlist and the user has declared it in I as list, then under some natural assumptions about ordering in the abstract domain we conclude that [[P ]] + I , i.e., the program is correct w.r.t. the declared I (or more precisely w.r.t. (I )). However, the program may still be incorrect w.r.t. the precise intention I, which is not given by the declaration. Example 5.3 Assume now that [[P ]] + 6 I . We cannot conclude that P is correct w.r.t. I . We cannot conclude the contrary either. For example if the abstract interpretation tells that the type of the predicate p with one argument position is list while the user declares it as intlist then P may still be correct w.r.t. the declaration. This can be due to the loss of accuracy introduced by the abstraction. In any case it may be desirable to localize a fragment of the program responsible for this discrepancy. A more careful inspection would then be needed to check whether the fragment is erroneous w.r.t. the declaration, or not. If analysis information allow us to conclude that the program is incorrect or incomplete w.r.t. I , an (abstract) symptom has been found which ensures that the program does not satisfy the requirement. Thus, a diagnosis should be performed to locate the program construct responsible for the symptom. We are studying the possibility of using for that purpose the conditions in Table 2, in a similar way as done in abstract diagnosis [CLMV96b]. 6 Towards an Integrated Validation and Diagnosis Environment In the previous sections we have addressed the problem of validation and diagnosis of a program with respect to incomplete requirements. We have hopefully contributed to clarifying how known veri cation and debugging techniques can be combined to support the process of program development, specially in the case in which approximations are used. This nal section discusses the design of an environment integrating validation and diagnosis tools making an extensive use of semantic approximations. The development of an environment of this kind is one of the objectives of the DiSCiPl project. The design of the language for expressing semantic approximations is an essential part of this task since the language is crucial for the user interface for the integration of di erent tools. We discuss some possibilities regarding the design of this language, some aspects of the debugging process, and the structure of the environment itself. 6.1 Assertion Languages An assertion is a linguistic expression which uniquely identi es an element x of the semantic domain D. The role of assertions is to express approximations of the program semantics, thus we expect that an assertion includes also an indication concerning the kind of approximation it is intended to express. The approximations we propose to allow in assertions are again those introduced in Section 4, i.e., f+; ; !g. In practice, assertions can be used to describe not only the intended semantics but also the actual semantics of the program (an example of the latter is the use of assertions to express the result of program analysis in [BCHP96]). We now consider several possible choices for the language of assertions. Notice that di erent kind of semantics may be used for validation and for debugging, thus the choices discussed below are parameterized by the semantic domain used. Note that semantic values in our setting are sets. Thus the assertions have to describe sets. One can adopt for that purpose some of the standard notations. For example formulae of rst-order predicate calculus with appropriate interpretation may be used for that purpose. When using a particular abstract domain for program analysis for abstract debugging, or for validation, it may be more convenient to introduce a specialized language referring to the elements 11 of this domain. The language of types inferred by some abstract interpretation is a typical example of this kind. An assertion of such a language corresponds to an element of the abstract domain. The concretization function maps it to the concrete domain. An advantage of using assertions specialized for a given abstract domain is that they facilitate interaction between the user and the tools. For example, when working with types it can be more natural to express and compare types inferred by the system and types declared by the user, rather than types obtained from assertions about the program which were not expressed in terms of types. It is also possible to consider assertions written in a di erent abstract domain than the one used for comparison. The limitation when using the abstract domain(s) is that the semantic objects which can be described are limited to those which are present as elements of the di erent abstract domains available in the tools. Another alternative is to express assertions in the (subset of) the same programming language i.e., an assertion for a program P is another program A, thus the semantic object indicated by A is [[A]]. For example, Prolog programs are used as assertions in the tool discussed in Section 4.1, and the restricted set of regular programs [GdW94] can be used as type assertions in the CIAO system. Assertions in the form of programs can be seen as executable speci cations. Such a program may be used to compute elements of the set speci ed by it. This technique is especially useful in higher level languages such as CLP, where the result of a computation may be a nite representation of an in nite set. An additional advantage of using programs as assertions is that the assertions themselves can be used as run-time tests in the cases in which the desired properties cannot be proven automatically (see Section 6.3). Notice that assertions written in di erent assertion languages refer to the same semantic domain. Therefore it may be desirable to develop techniques of combining them for purposes of speci cation. Example 6.1 In the case of the D-model semantics a language of D-constraints including some basic constraints and closed un

https://www.ep.liu.se/ea/cis/1997/009/13/cis9700913.pdf

On the Role of Semantic Approximations on Validation and Diagnosis of Contraint Logic Programs

https://link.springer.com/content/pdf/10.1007%2FBFb0014980.pdf

Inductive assertion method for logic programs

Algorithmic debugging, as presented by Shapiro, is an interactive process where the debugging system acquires knowledge about the expected meaning of a program being debugged and uses it to localize errors. This paper suggests a generalization of the language used to communicate with the debugger. In addition to the usual “yes” and “no” answers, formal specifications of some properties of the intended model are allowed. The specifications are logic programs. They employ library procedures and are developed interactively in the debugging process. An experimental debugging system incorporating this idea has been implemented. In contrast to some other systems, its diagnosis algorithms do not require instantiation of unsolved goals by the oracle. This is achieved by generalization of the oracle in the incorrectness algorithm, and by adopting a new approach in the insufficiency algorithm. A formal proof of correctness and completeness of the new insufficiency algorithm is presented. Extensions for some Prolog features are discussed.

Algorithmic Debugging with Assertions.

A standard approach to negation in logic programming is negation as failure. Its major drawback is that it cannot produce answer substitutions to negated queries. Approaches to overcoming this limitation are termed constructive negation. This work proposes an approach based on construction offailed trees for some instances of a negated query. For this purpose a generalization of the standard notion of a failed tree is needed. We show that a straightforward generalization leads to unsoundness and present a correct one.

Wlodzimierz Drabent

Papers

On the Role of Semantic Approximations on Validation and Diagnosis of Contraint Logic Programs

Inductive assertion method for logic programs

Algorithmic Debugging with Assertions.

What is failure?: an approach to constructive negation

The Use of Assertions in Algorithmic Debugging.