Global data-flow analysis of (constraint) logic programs, which is generally based on abstract interpretation [7], is reaching a comparatively high level of maturity. A natural question is whether it is time for its routine incorporation

in standard compilers, something which, beyond a few experimental systems, has not happened to date. Such incorporation arguably makes good sense only if:

• the range of applications of global analysis is large enough to justify the additional complication in the compiler, and

• global analysis technology can deal with all the features of "practical" languages (e.g., the ISO-Prolog built-ins) and "scales up" for large programs.

We present a tutorial overview of a number of concepts and techniques directly related to the issues above, with special emphasis on the first one. In particular, we concéntrate on novel uses of global analysis during program

development and debugging, rather than on the more traditional application área of program optimization. The idea of using abstract interpretation for validation and diagnosis has been studied in the context of imperative programming [2] and also of logic programming. The latter work includes issues such as using approximations to reduce the burden posed on programmers by declarative debuggers [6, 3] and automatically generating and checking assertions [4, 5] (which includes the more traditional type checking of strongly typed languages, such as Gódel or Mercury [1, 8, 9]) We also review some solutions for scalability including modular analysis, incremental analysis, and widening. Finally, we discuss solutions for dealing with meta-predicates, side-effects, delay declarations,  constraints, dynamic predicates, and other such features which may appear in practical languages. In the discussion we will draw both from the literature and from our  experience and that of others in the development and use of the CIAO system analyzer. In order to emphasize the practical aspects of the solutions discussed, the presentation of several concepts will be illustrated by examples run on the CIAO system, which makes extensive use of global analysis and assertions

Hermenegildo, Manuel V.

English

Servicio de Coordinación de Bibliotecas de la Universidad Politécnica de Madrid

Programming with Global Analysis 
M a n u e l H e r m e n e g i l d o 
T h e C L I P Group 
School of C o m p u t e r Science 
Technical Universi ty of Madr id 
herme@fi.upm.es 
Abstract 
Global data-flow analysis of (constraint) logic programs, which is generally 
based on abstract interpretation [7], is reaching a comparatively high level 
of maturity. A natural question is whether it is time for its routine incorpo-
ration in standard compilers, something which, beyond a few experimental 
systems, has not happened to date. Such incorporation arguably makes good 
sense only if: 
• the range of applications of global analysis is large enough to justify 
the additional complication in the compiler, and 
• global analysis technology can deal with all the features of "practical" 
languages (e.g., the ISO-Prolog built-ins) and "scales up" for large 
programs. 
We present a tutorial overview of a number of concepts and techniques 
directly related to the issues above, with special emphasis on the first one. 
In particular, we concéntrate on novel uses of global analysis during program 
development and debugging, rather than on the more traditional application 
área of program optimization. 
The idea of using abstract interpretation for validation and diagnosis has 
been studied in the context of imperative programming [2] and also of logic 
programming. The latter work includes issues such as using approximations 
to reduce the burden posed on programmers by declarative debuggers [6, 3] 
and automatically generating and checking assertions [4, 5] (which includes 
the more traditional type checking of strongly typed languages, such as Gódel 
or Mercury [1, 8, 9]) 
We also review some solutions for scalability including modular analysis, 
incremental analysis, and widening. Finally, we discuss solutions for dealing 
with meta-predicates, side-effects, delay declarations, constraints, dynamic 
predicates, and other such features which may appear in practical languages. 
In the discussion we will draw both from the literature and from our ex-
perience and that of others in the development and use of the CIAO system 
analyzer. In order to emphasize the practical aspects of the solutions dis-
cussed, the presentation of several concepts will be illustrated by examples 
run on the CIAO system, which makes extensive use of global analysis and 
assertions. 
References 
[1] K. R. Apt and E. Marchiori. Reasoning about Prolog programs: from modes 
through types to assertions. Formal Aspects of Computing, 6(6):743-765, 1994. 
[2] F. Bourdoncle. Abstract debugging of higher-order imperative languages. In 
Programming Languages Design and Implementation'93, pages 46-55, 1993. 
[3] J. Boye, W. Drabent, and J. Maluszyñski. Declarative diagnosis of constraint 
programs: an assertion-based approach. In Proc. of the 3rd. Int'l Workshop on 
Automated Debugging-AADEBUG'97, pages 123-141, Linkoping, Sweden, May 
1997. U. of Linkoping Press. 
[4] F. Bueno, D. Cabeza, M. Hermenegildo, and G. Puebla. Global Analysis of 
Standard Prolog Programs. In European Symposium on Programming, number 
1058 in LNCS, pages 108-124, Sweden, April 1996. Springer-Verlag. 
[5] F. Bueno, P. Deransart, W. Drabent, G. Ferrand, M. Hermenegildo, 
J. Maluszyñski, and G. Puebla. On the Role of Semantic Approximations in 
Validation and Diagnosis of Constraint Logic Programs. In Proc. of the 3rd. Int'l 
Workshop on Automated Debugging-AADEBUG'97, pages 155-170, Linkoping, 
Sweden, May 1997. U. of Linkoping Press. 
[6] M. Comini, G. Levi, M. C. Meo, and G. Vitiello. Proving properties of logic 
programs by abstract diagnosis. In M. Dams, editor, Analysis and Verification 
of Múltiple-Agent Languages, 5th LOMAPS Workshop, number 1192 in Lecture 
Notes in Computer Science, pages 22-50. Springer-Verlag, 1996. 
[7] P. Cousot and R. Cousot. Abstract Interpretation: a Unified Lattice Model for 
Static Analysis of Programs by Construction or Approximation of Fixpoints. 
In Fourth ACM Symposium on Principies of Programming Languages, pages 
238-252, 1977. 
[8] P. Hill and J. Lloyd. The Goedel Programming Language. MIT Press, Cambridge 
MA, 1994. 
[9] Z. Somogyi, F. Henderson, and T. Conway. The execution algorithm of Mer-
cury: an efficient purely declarative logic programming language. JLP, 29(1-3), 
October 1996. 


Programming with global analysis

Slide 0
Programming with Global Analysis
M. Hermenegildo1
in collaboration with
G. Puebla1 F. Bueno1 P. Deransart2
W. Drabent3 G. Ferrand4 J. Małuszyn´ski5
1Technical University of Madrid
2INRIA-Rocquencourt
3Polish Academy of Sciences
4University of Orle´ans
5Linko¨ping University
(Partially Supported by ESPRIT Project DiSCiPl:
Debugging Systems for Constraint Programming.)
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 1
Introduction
 Much progress made in global program analysis,
generally based on abstract interpretation.
 Current results/systems allow:
 Inferring non-trivial information
(from types and modes to cost, termination, non-failure...)
 Dealing with full languages and large (modularized) programs.
 Results have been applied generally to program transformation/optimization.
 Tutorial objective: explore applications in program development.
 In particular, in validation and diagnosis.
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 2
Validation and Diagnosis
 Users expect programs to satisfy certain requirements (specifications).
 Requirements may be:
 proved to hold (i.e., they are verified),
 or to be violated (i.e., a symptom is detected).
 Diagnosis: identifying the part of the program responsible for the violation.
 The traditional approach generally uses two (separate) mechanisms, e.g.:
 Run-time testing:
Program
Specific.
:- check
Annotator
RT-test Program +
RT-tests
 Proof-based validation (generally, non-automated).
(Exception: types.)
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 3
Actual and Intended Semantics
 Semantics associate a meaning to a given syntax.
 A meaning is an element of a semantic domain (D).
 Semantics allow:
 capturing the characteristics (observables) of interest,
 while hiding others which are not relevant.
 We consider the class of fixpoint semantics, using sets:
 Actual semantics of a program P is [[P ]] and corresponds to a set.
 [[P ]] is the least fixpoint of a semantic operator S
P
.
 Program validation and diagnosis both compare actual semantics [[P ]] of the
program with an intended semantics I for the same program.
 I can be seen as the semantics of an intended program
(which does not exist in general).
 Usually, only partial descriptions of I are available.
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 4
Program Validation Tasks
 Set theoretic definition of validation tasks:
 P is partially correct w.r.t. I iff [[P ]]  I.
 P is complete w.r.t. I iff I  [[P ]].
 P is incorrect w.r.t. I iff [[P ]] 6 I.
 P is incomplete w.r.t. I iff I 6 [[P ]].
 Incorrectness and incompleteness indicate that diagnosis should be performed.
 Problem: difficulty in computing [[P ]].
 Possible solutions / alternatives:
 Proving sufficient conditions (as in diagnosis by proof ).
 Program testing, run-time checking, manual tracing, etc.
(but incomplete and generally expensive)
 Approximating [[P ]] directly (safely)
(approximate or abstract validation [Bourdoncle93], [ESOP’96], ...).
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 5
Approximating the Intended Semantics
 Using the exact intended semantics for validation and diagnosis is in general also
not realistic because I may be:
 only partially known,
 infinite,
 too expensive to manipulate, ...
 We consider three types of approximations:
 Superset (A+): A  A+.
 Subset (A ): A   A.
 Existential (A!): A! \ A 6= ;.
 For example, in [DNTM89] the approximations used were of types
I
 
, ( I )
!
, I
! and I+ or, equivalently, ( I ) .
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 6
Examples of Intended Semantics
 Given:
sorted([]).
sorted([_]).
sorted([X,Y|Z]) :- X > Y, sorted([Y|Z]).
 A subset of the programmer’s intentions:
I
1
= fsorted([X ]) j X is an integerg
 A superset of the programmer’s intentions:
I
2
= fsorted(L) j L is a list of integersg
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 7
Assertion Languages
 Assertion: expression which identifies an element of D.
 Depends on the semantic domain D (in our case, it has to describe sets).
 Examples of possible assertion languages:
 Any language that can describe sets
(e.g., formulas of first order predicate calculus).
 A specialized language over an “abstract domain” (e.g., types).
 The source language – some examples:
Prolog programs used as assertions in [DNTM89].
Prolog programs used as types and properties in the CIAO system [ESOP’96].
* Specially useful in higher-level logic languages (e.g., LP, CLP).
* The properties in the assertions can be used as run-time tests.
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 8
Assertions (and Properties)
 Multiple uses/roles:
 Run-time checking (e.g., pre/post-cond) – general properties, ”check”.
 Compile-time checking (e.g., types) – decidable, compulsory, ”check”.
 Replacing the oracle – general declarative properties, ”check”.
 Providing info to optimizer (e.g., pragmas) – general properties, ”trust”.
 General comm. w/compiler (e.g., entry, trust) – general properties, ”trust”.
 Objectives:
 Propose an assertion language suitable for all these purposes.
(When possible, keep backwards compatibility w/ISO & popular platforms.)
 Study formally interaction with different debugging tools (and implement!).
 Important issue: whole system should deal safely with general, undecidable
properties, and incomplete information ! safe approximations.
 Different program development tools may use different parts of the language.
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 9
An Assertion Language: Properties
 Arbitrary predicates, (generally) written in the source language.
 Some predefined in system, others user-defined.
 Should terminate (but code may be an approximation of the property).
 Types are just a special case (example: regular programs).
 Some examples (all examples are in CIAO assertion syntax – see [ILPS’97 WS]):
:- property sorted/1. | :- typedef list : [];[_|list].
sorted([]). |_________________________________
sorted([_]). | :- type integer/1.
sorted([X,Y|Z]) :- X>Y, sorted([Y|Z]).| % is built-in
______________________________________|_________________________________
:- type list/1. | :- type peano_int/1.
list([]). | peano_int(0).
list([_|Y]) :- list(Y). | peano_int(s(X)) :- peano_int(X).
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 10
Declarative Assertions: Superset and Subset
 Written by the user, optional — they describe the intended semantics (I).
 Two kinds:
 “Superset” assertions:
:- inmodel Pred => Props.
* Describe (a superset of) the results of a predicate.
* Used for correctness debugging (violation is a symptom).
* Example:
:- inmodel qsort(A,B) => list(B).
 “Subset” assertions:
:- inmodel Pred <= Props.
* Describe (a subset of) the results of a predicate.
* Used for completeness debugging (violation is a symptom).
* Example:
:- inmodel qsort(A,B) <= (A==[2,1],B==[1,2]).
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 11
Basic Operational Predicate Assertions: Success
 Written by the user, optional — describe intended (operational) semantics (I).
 All “superset.”
 Properties should apply to all run-time invocations of a predicate.
 “Success” assertions:
:- success Pred => PostCond.
 Describe post-conditions of a predicate.
 Any declarative superset assertion is also a success assertion
(due to correctness of the operational semantics).
 Example:
:- success qsort(A,B) => list(B).
 Restricting to a subset of calls:
:- success Pred : PreCond => PostCond.
 Example:
:- success qsort(A,B) : list(A) => list(B).
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 12
Basic Operational Predicate Assertions: Calls and Comp
 “Calls” assertions:
:- calls Pred : Props.
 Describe properties of the calls to a predicate.
 Example:
:- calls qsort(A,B) : (list(A),var(B)).
 “Comp” assertions:
:- comp Pred : PreCond + CompProps.
 Describe props of predicate execution (determinacy, non-failure, cost, ...).
 Example:
:- comp qsort(A,B) : (intlist(A),var(B)) + (det,no_fail).
 Most general, but others always preferred if possible.
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 13
Compound Operational Predicate Assertions: Pred Assertions
 Issues in practice with previous assertions:
 Verbose in some cases: more compact notation desired.
 Closedness of calls in multiple success assertions.
 “Pred” assertions:
:- pred GoalPattern [ : Pre ] [ => Post ] [ + Comp ].
(Fields in [...] are optional.)
 Several form a conjunction (if several match ! then GLB).
 Assumed to be closed (cover all uses of the predicate).
 Some examples:
 :- pred qsort(X,Y) => sorted(Y).
 :- pred qsort(X,Y) : (intlist(X),var(Y)) => sorted(Y) + no_fail.
 :- pred foo(X,Y) : (ground(X),var(Y)) => (ground(Y),X>Y) + det.
:- pred foo(X,Y) : (var(X),ground(Y)) => (ground(X),X>Y).
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 14
Other Assertions
 “Program point” assertions:
 Properties of program points between literals in clauses.
..., Literal, check(Cond), Literal, ...
 Example:
p(X) :- q(X,Y), check((X>Y,Y>=0), r(Y).
 Two types of properties:
* State properties: refer to current execution state.
* Forward properties: may refer to future execution states.
p(X) :- q(X,Y), check(fwd((X>0),format("~w not >0!",[X]))), ...
 Many other possibilities.
E.g. (CIAO) additional optional field for automatic documentation (pl2texi):
:- pred GoalPattern : C => S + G ; Comment.
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 15
Approximating the Actual Semantics
 Computing the actual program semantics ([[P ]]) is generally difficult (the
computation process and/or the semantic object are often infinite).
 Program analysis techniques aim at computing approximations of [[P ]].
 One of the most successful, well founded techniques is abstract interpretation
[CC77].
 Abstract interpretation techniques have been used for:
 debugging of imperative languages [Bourdoncle93],
 diagnosis by proof of logic programs [CLMV96],
 validation of logic and constraint programs (generation and checking of
abstract assertions) [ESOP’96]
 We describe the use of abstract interpretation in abstract validation for arbitrary
fixpoint semantics (see [AADEBUG’97] for other applications).
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 16
Abstract Interpretation [CC77]
 Compute over abstract values: finite representation of a, possibly infinite, set of
values in the concrete domain (D).
 An abstract domain D

is the set of all possible abstract semantic values.
 D and D

are related via a pair of monotonic mappings h; i:
 abstraction  : D 7! D

 concretization  : D

7! D
such that:
 8x 2 D : ((x))  x, and
 8y 2 D

: ((y)) = y.
i.e., h; i conform a Galois insertion
over D and D

.
 Example: (types)
D = f1; 2; 3; : : :g; (f2; 4g) = even; (even) = f2; 4; : : :g; even 

even = even
  
  
  
  
  






D

D

Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 17
Abstract Interpretation (cont.)
 An abstract semantic operator S
P
can be defined which is correct w.r.t. S
P
.
 lfp(S

P
) is denoted by [[P ]]

.
 The following relations hold:
 8x 2 D : (S

P
((x))  S
P
(x)
 ([[P ]]

)  [[P ]] equivalently [[P ]]

 ([[P ]]).
 An abstract operator S
P
is said to be precise if it satisfies:
 ([[P ]]

) = [[P ]] equivalently [[P ]]

= ([[P ]]).
 Galois insertions normally over-approximate [[P ]].
 Example: type inference.
 It is possible to work dually (and under-approximate [[P ]]) by simply replacing 
with .
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 18
Assertions in Program Analysis: Analyzer Output
 Additional prefix/concepts: check, true (and, later trust).
 All previous assertions are “check” (i.e., this is default).
 “True” assertions: have been proved to hold.
(e.g., output from the analyzer / assertion checker).
 Example:
:- true success p(X) : ground(X).
 Also, program point output. Example:
p(X,Y):-
true(ground(X)),
q(X,Z),
true((ground(X),ground(Z))),
r(Z,Y),
true((ground(X),ground(Y),ground(Z))).
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 19
Guiding the Analysis
 “Entry” assertions: describes external calls to a predicate.
 Example:
:- entry q(X,Y) : (ground(X),var(Y)).
 “Trust” assertions: have to be assumed to hold.
(e.g., guiding the analyzer / assertion checker).
 Example:
:- trust success p(X) : ground(X).
 Predicate, if present, still has to be analyzed.
 In some cases, results of analysis may:
* improve precision,
* or even detect errors in trust declarations.
 Very useful also for modular analysis, etc. [ESOP’96]
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 20
Using Analysis in Debugging
 Direct observation of compiler output can detect many bugs:
 type errors,
 mode errors (e.g., builtins),
 infinite loops,
 possible failure,
 ...
 even inefficiencies (cost analysis).
 Objective: automate the process.
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 21
Integrated Validation and Diagnosis Based on Approximations
:- trust
:- entry
Specific.
:- check
:- holds
Comparator
Program RT-test
Annotator
Program +
RT-tests
:- check
Errors
(or user)
Declarative
/ Abstract
Diagnoser
Analyzer
(abstract
interpreter)
:- true
:- false
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 22
Validation Using Abstract Interpretation [AADEBUG’97]
 Specification given as a semantic value I

2 D

and compared with [[P ]]

.
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 ]]

+
([[P ]]

+
represents that [[P ]]

 ([[P ]]) and [[P ]]

 
indicates that [[P ]]

 ([[P ]]))
 Conclusions w.r.t. Galois insertions:
 Suited for proving partial correctness and incompleteness w.r.t. I.
 It is also possible to prove incorrectness.
 Completeness can only be proved if the abstraction is “precise.”
 Conclusion w.r.t. reversed Galois insertions:
 Suited for proving completeness and incorrectness.
 Partial correctness and incompleteness only if the abstraction is “precise.”
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 23
The feedback loop
:- trust
:- entry
Specific.
:- check
Analyzer :- holds
Comparator
Program RT-test
Annotator
Program +
RT-tests
:- check
/ Abstract
Diagnoser
Declarative
Errors
:- true
:- false
 Program construction: an iterative process.
 Not only program but also requirements updated incrementally.
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997
Slide 24
Conclusions
 Global analysis w/approximations: important role also in program development.
 It allows going beyond the straight-jacket of traditional types:
Types Properties
Compulsory (do not allow “any”) Optional (allow “any”)
“check” “check” or “trust”
Expressed in a Special Language Expressed in the Source Language
Limited Property Language Much More General Property Language
Limit Programming Language Do not Limit Programming Language
Untypable Programs Rejected Run-time Checks Introduced
(Almost) Decidable Approximated
...without giving up much: types are included as just another kind of property.
 Key issues:
Approximation Suitable assertion language
Abstract Interpretation Relating aproximations of actual and intended semantics
 See pointers in “http://www.clip.dia.fi.upm.es/” (also, paper(s) in env. WS).
Manuel Hermenegildo – Programming with Global Analysis ILPS’97 Tutorial – Port Jefferson, October 1997


Programming with Global Analysis

Archivo Digital UPM

Abstract debugging of higher-order imperative languages.

Abstract Interpretation: a Unified Lattice Model for Static Analysis of Programs by Construction or Approximation of Fixpoints.

Declarative diagnosis of constraint programs: an assertion-based approach.

Global Analysis of Standard Prolog Programs.

On the Role of Semantic Approximations in Validation and Diagnosis of Constraint Logic Programs.

Proving properties of logic programs by abstract diagnosis.

Reasoning about Prolog programs: from modes through types to assertions.

The execution algorithm of Mercury: an efficient purely declarative logic programming language.

The Goedel Programming Language.

http://oa.upm.es/14792/1/HERME_NB_1997-1.pdf

Programming with global analysis

Abstract

Similar works

Full text

Available Versions

Servicio de Coordinación de Bibliotecas de la Universidad Politécnica de Madrid

Servicio de Coordinación de Bibliotecas de la Universidad Politécnica de Madrid

Archivo Digital UPM

Archivo Digital UPM