On the Role of Semantic Approximat ions in Validation and Diagnosis of Constraint Logic Programs ( Extended Abstract )

diagnosis searches for incorrectness and incompleteness errors as defined in Section 3.2, using the sufficient conditions given in Table 2. The semantic operator Sp is replaced by Sp, in a similar way to abstract interpretation. Unlike abstract interpretation, no fixpoint computation is needed and Ifp(Sp) is not computed. Two different kind of observables are considered in [CLMV96a]. Complete observables provide stronger results but are often not practical because the specification of the intended semantics Xa is infinite 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 Sp 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 principie. The proof attempt may succeed in which case the program satisfies the requirement I (expressed as Xa), and abstract diagnosis works as validation. An alternative way of validation is to compute abstract approximations [P] Q of the actual semantics of the program |P]] and then use the definitions given in Table 1 instead of the sufficient 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 specification is given as a semantic valué Ia £ Da. Comparison between actual and intended semantics of the program should be done in the same domain. Thus, for comparison we need in principie cc([[Pj). However, using abstract interpretation, we instead compute [P]]Q, which is an approximation of cc([[Pj), and can be compared with Ia. We will use the notation [P]]Q,+ to represent that \P\a 2 a ([-?*]])• I-P]Qindicates that [P]]Q C a([[P]]). Table 5 gives sufficient conditions for correctness and completeness w.r.t. Ia which can be used when [P] is approximated.diagnosis localizes suspected program constructs following the diagnosis by proof principie. The proof attempt may succeed in which case the program satisfies the requirement I (expressed as Xa), and abstract diagnosis works as validation. An alternative way of validation is to compute abstract approximations [P] Q of the actual semantics of the program |P]] and then use the definitions given in Table 1 instead of the sufficient 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 specification is given as a semantic valué Ia £ Da. Comparison between actual and intended semantics of the program should be done in the same domain. Thus, for comparison we need in principie cc([[Pj). However, using abstract interpretation, we instead compute [P]]Q, which is an approximation of cc([[Pj), and can be compared with Ia. We will use the notation [P]]Q,+ to represent that \P\a 2 a ([-?*]])• I-P]Qindicates that [P]]Q C a([[P]]). Table 5 gives sufficient conditions for correctness and completeness w.r.t. Ia which can be used when [P] is approximated. Property P is partially correct w.r.t. Ia P is complete w.r.t. Ia P is incorrect w.r.t. Ia P is incomplete w.r.t. Ia Definition a(lPl) C la la C a(lPj) a(lPÍ) <¿ 1* la 1 a(lPj) Sufficient condition PTU c xa Za C [Pj„_ [ P j a _ £ la, or lP}a+ n i a = 0 A [ P ] a # 0 i« 2 IPU Table 5: Validation problems using approximations The following conclusions can be drawn from Table 5. Analyses which use a Galois insertion ( a + , 7 + ) , and thus over-approximate the actual semantics (Le., those denoted as [P] a+) are specially suited for proving partial correctness and incompleteness with respect to the abstract specification la. 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 specification, Le., when [P]]a+ n l „ = 0 . Note that it will only be possible to prove completeness if the abstraction is precise. According to Table 5 only [P]]Qcan be used at this end, and in the case we are discussing [P]Q+ holds. Thus, the only possibility is that the abstraction is precise. On the other hand, if a reversed Galois insertion is used (a~,y~), and then analysis underapproximates the actual semantics (the case denoted [ P ] a ) , 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 ( a + , 7 + ) are in essence equivalent to the ones presented for abstract diagnosis [CLMV96a] for approximate observables. In the case 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\a+ the type of a predícate p with just one argument position is intlist and the user has declared it in Ia as list, then under some natural assumptions about ordering in the abstract domain we conclude that [-P]]Q+ C Ia, Le., the program is corred w.r.t. the declared Ia (or more precisely w.r.t. j(Ia)). 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]Q+ 2 Za. We cannot conclude that P is corred w.r.t. Ia. We cannot conclude the contrary either. For example if the abstract interpretation tells that the type of the predícate p with one argument position is list while the user declares it as intlist then P may still be corred w.r.t. the declaration. This can be due to the loss of accuracy introduced by the abstradion. 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. Ia, an (abstract) symptom has been found which ensures that the program does not satisfy the requirement. Thus, a diagnosis should be performed to lócate 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 verification and debugging techniques can be combined to support the process of program development, specially in the case in which approximations are used. This final 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 different 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 identifies 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, Le., {+, —,!} . 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 different 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 valúes 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 first-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 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 facilítate 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 different 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