Obvious erties sf Co uter Programs

Robert Divan

Department of Computer Science Brown University, Box 1910, Providence, RI 02912

rlg@cs.brown.edu, http:// www.cs.brown.edu/people/rlg/

Abstract

We explore the question of what properties of LISP programs can be made “obvious” to a computer sys- tem. We present a polynomial-time algorithm for in- ferring interesting properties of pure LISP programs. Building on previous work in knowledge representa- tion for rapid inference, we present a language for rep- resenting properties of programs. We treat properties as generalized types, i.e., sets of program values. The property language is expressive enough to represent any RE set of LISP values as a property, and can nat- urally represent ,a wide variety of useful properties.

We then use a general technique to construct a polynomial-time property inference relation and use type-inference style program analysis to integrate this relation into an algorithm for inferring properties of programs. This algorithm is intended to work in the context of a library of background information, most of which is typically derived from previous runs of the algorithm. Due to the expressive representation sys- tem, no algorithm can infer every valid property- so instead of proving completeness we show our al- gorithm’s usefulness by giving examples of properties inferred. These examples include that insertion sort returns a sorted permutation of its input, and that a clique finding program correctly returns a clique.

Introduction Programmers quickly and easily see many properties of their programs that are invisible to program anal- ysis systems. We find it obvious, for example, that concatenating two lists produces a list at least as long as either, or that mapping a function across a list pro- duces a list of the same length. But these properties typically cannot even be represented by compilers.

Theorem provers can represent such properties, but provide little counterpart for the quick reasoning of hu- mans. In this paper, we explore the question “How strong1 can we make a fast inference procedure?“, where we formalize “fast” as “polynomial-time”, and

Copyright @ 1997, American Association for Artificial Intelligence (www.aaai.org). All Rights Reserved.

I We are using “stronger” here to refer to the partial order that relates two inference procedures when one always infers a strict superset of the theorems the other infers.

404 KNOWLEDGE REPRESENTATION

we are especially interested in inferring properties that require expressive representation to state.

The answer to this question proves very sensitive to the representation system used in inference. We draw on our previous work with McAllester(l993; 1992) to select a representation for program proper- ties amenable to rapid inference. This representation derives from viewing properties as sets of program values-a program has a property if the program re- turns a value in the corresponding set of values. Tak- ing this view, program properties are essentially just types in a rich type system, and we exploit this fact by drawing on traditional type inference techniques in constructing our inference algorithm.

Related previous work on polynomial-time inference has frequently achieved the polynomial-time bound largely by limiting the expressiveness of the lan- guage of inferrable properties(Brachman & Schmolze 1985)(Nebel 1990). Th is approach is attractive be- cause the resulting system is typically amenable to proofs of completeness theorems asserting that every valid representable property will be inferred. How- ever, this approach limits the strength of the resulting procedure. Expressive language constructs not only facilitate the asking of hard questions (causing incom- pleteness), but also facilitate reasoning. There are in addition many questions that can be easily answered but can only be asked in an expressive language. In this paper we consider the effects of allowing a richly expressive language (any 7U set can be represented as a property), but insisting that our inference principles remain within polynomial-time.

Work on fast decision procedures in theorem prov- ing is also closely related to this paper.(Nelson & Op- pen 1980) C on g ruence closure, which decides the lit- eral set satisfiability problem for the first-order theory of equality, is a polynomial-time procedure that has proven very useful in theorem proving(Owre, Rushby, & Shankar 1992). Congruence closure can be easily and naturally integrated with the inference techniques in this paper, and this work can be viewed as an ex- tension of congruence closure (the extension addresses an undecidable problem, unlike congruence closure).

Since the problem we are addressing is undecidable, we cannot hope to demonstrate the adequacy of our

From: AAAI-97 Proceedings. Copyright © 1997, AAAI (www.aaai.org). All rights reserved.

inference algorithm with a completeness theorem. In- stead, we give examples of the kind of properties we can hope to infer with this algorithm. Unfortunately, but intrinsically, we do not have a clean characteri- zation of the set of inferrable properties-the demand for such a characterization is one of the fetters we are throwing aside in search of stronger fast inference.

Nevertheless, it is important to have some means of evaluating our procedures. The examples contained herein are just a start-we envision and desire the de- velopment of a large corpus of such examples of pro- grams and associated inferrable properties. Of course, for any such corpus there is a constant time algorithm that infers all the listed properties-what we really de- sire is a large corpus that can be handled by a single relatively simple polynomial-time algorithm. The al- gorithm we present below is intended only as a start in this direction-we believe more inference principles will need to be added to it to achieve the desired gen- erality. Still, this algorithm gives interesting results on the examples exhibited, and was not designed with them specifically in mind. Our primary intent is to convince the reader that an algorithm of this sort can make interesting progress in the undecidable domain of general purpose property inference, and do so within polynomial-time.

Languages hr rograms and We introduce the programming language and our rep- resentation for properties. We give as examples the program definitions of insertion sort and of a clique finding algorithm, and the property definitions of a permutation of a list, a sorted list, and a clique. In the next section we describe a polynomial-time algo- rithm that infers relationships between these programs and properties (e.g. that sort permutes its input).

Prsgram Expressions The programming language we analyze is a typed, first-order, pure subset of LISP. It is “first-order” because, to ease the presentation, it does not include first class functions-user functions are introduced through definitions and used only by being applied-however, this work generalizes natu- rally to first class functions. The language is “typed” because it requires each variable to be given a user pro- vided type at its introduction; these types are given in an expressive property language and can capture much about the programmer’s intended use for the variable. Program expressions are defined inductively as follows:

e **- ..- z 1 (let 2:e el) 1 (f el -m-e,)

1 (if e : p* el ea) 1 ‘sym

where z can be any variable, f can be cons, car, cdr, or any n-ary program function-symbol, sym can be any symbol and p* must be a testable property (see below). The intended meanings for the above program expres- sions should be clear from LISP, except that the if tests are new: e :p is true if the value e satisfies the

property p (see below). Example program expressions appear in the definitions in figure 1.

(define (insert x:(a-number) l:(a-sorted-list)) (if l:'nil

(cons x 1) (if x:0= (car 1))

(cons x 1) (cons (car 1) (insert x (cdr l>>>>>>

(define (sort l:(a-numlist)) (if 1:'nil

1 (insert (car 1) (sort (cdr 1)))))

(define (intersect li:(a-list) 12:(a-list)) (if 1l:'nil

'nil (if (car ll):(a-member-of 12)

(cons (car 11) (intersect (cdr 11) 12))

(intersect (cdr 11) 12))))

(define (largest-clique-in s:(a-list>> (if s:'nil

'nil (let n:(car s>

c:(cons n (largest-clique-in (intersect (neighbors n>

(cdr s>>>> c':(largest-clique-in (cdr s>>>

(if (length c>:(>= (length c'>>

L,,,

(define (delete x:(a-thing) l:(a-list))

(if l:'nil 'nil (if x:(car 11

(cdr 1) (cons (car l> (delete x (cdr 1))))))

Figure 1: Example program defini&ions. We omit simple definitions which have no effect on the example inferences claimed later (length, neighbors)

Property Expressions Our property language is derived from our previous work with McAllester( 1992) on natural language syntax and its relationship to tractable inference. The representational features in- troduced in that work have never before been ex- ploited in an automated reasoning system. Our prop- erty language is essentially the programming language extended by some new constructs that allow and facil- itate the quantifier-free construction of sets of values. The most important of these constructs is nondeter- minism. We use nondeterminism for its declarative value only-property expressions are not programs to be run. A property expression has in general many possible values via nondeterminism-the set of these values is the type (property) represented by the expres- sion. Using recursion, property expressions can denote

AUTOMATEDREASONING 405

infinite sets. Nondeterminism is introduced by the one-of comb-

inator2. The expression (one-of s t) where s and t are property expressions denotes the nondeterministic choice between s and t. Alternatively, one-of can be viewed as the union operator on sets-(one-of s t) de- notes the union of the types (properties) represented by s and t. As an example, consider the property a-list in figure 2, which denotes the set of all finite LISP lists.

Nondeterminism further enhances the representa- tional power of our property language when considered in conjunction with function application. Consider the expression (2* (a-number) 1. This expression denotes the set of even numbers. This meaning can be derived by evaluating the expression nondeterministically3- first, the argument to 2* returns an arbitrary natural number, then 2* deterministically doubles this num- ber; the result can be any even number. A similar nondeterministic evaluation applies if we replace 2* with a nondeterministic “property function” such as greater-than (see figures 2 and 3 for examples).

(define (a-list) (one-of 'nil (cons (a-thing) (a-list))>)

(define (a-member-of l:(a-list)) (if 1:'nil

I (one-of (car 1) (a-member-of (cdr 1)))

** natural numbers (in unary) idefine (a-number)

(one-of 'nil (cons ‘a (a-number>)>> *I any list of numbers idefine (a-numlist)

>>

(one-of 'nil (cons (a-number) (a-numlist))))

;; the numbers >= x (define (>= x:(a-number))

(one-of x (cons 'a (>= x>>)>

Figure 2: Example Property Definitions

A final representational feature of our property lan- __ guage allows the quantifier-free construction of proper- ties that would traditionally require quantifiers. Given a (deterministic or nondeterministic) function f of one argument, and a property expression p, the expres- sion (f (every p) > is analogous to the ordinary ap- plication (f p) except that only output values that can be produced for every value p might return are kept. In other words, (f (every p) > denotes the set of values that are f-related to every value of p. As a

2one-of is closely related to amb introduced by Mc- Carthy in (McCarthy 1967)

31fyou have trouble understanding the intended mean- ing ofany ofourproperty definitions, we recommend trying this evaluation strategy.

(define (a-permutation-of l:(a-list)) (if 1:'nil

1 (let x:(a-member-of 1))

(cons x (a-permutation-of (delete x 1))))))

(define (a-sorted-list) (one-of 'nil

(let l:(a-sorted-list) (cons (all-of (>= (every (a-member-of 1)))

(a-number)) 1))))

(define (neighbor-of n:(a-thing)) (a-member-of (neighbors n)>>

(define (a-clique) (one-of 'nil

(let c:(a-clique)) (cons (a-neighbor-of

(every (a-member-of c))) cl>>>

Figure 3: More Example Properties

more concrete example, the notion of a common fac- tor of the numbers in a set s could be represented by the property (factor-of (every (member-of s))). This construction was introduced in (McAllester & Gi- van 1992), and is inspired by the English noun phrase construction “loves every man”. Its use in program analysis is new and essential-it allows the quantifier- free definition of useful properties like “sorted list” and facilitates the reasoning about these properties (other representations of these properties are more unwieldy, making the resulting inference task more difficult).

Formally, property expressions are defined as:

P ::= II: I (let z:PPl) I (if P1:P2 4233 P4)

I (fPr%) I (4 (everw)) I (one-ofs) I (all-of S)

1 (notp) I 'sym 1 I I (a-thing)

where f can be cons, car, cdr, or any defined program or property function symbol, sym any symbol, and s is a finite set of property expressions. Note that ev- ery program expression is also a property expression- when used as a property expression a program expres- sion denotes the singleton set containing the value of the program. This BNF includes some expressions not yet mentioned: (all-of s) denotes those values that are possible values of every expression in s, (not p> denotes those values that are not possible values of p, I denotes the empty set of values, and (a-thing) de- notes the set of all possible values (quoted symbols or finite cons expressions built up from them).

Programs We consider a sequence of function-sym- bol definitions to be a program. A function-symbol definition assigns to a new function-symbol either of

406 KNOWLEDGEREPRESENTATION

(lambda ~1 :pl, - - - ,x,:pn p) or (fix f xl:pl,-s-,x,: l)n p) where the body p must be deterministic (i.e. a program expression) if the symbol being defined is a program function-symbo14. The properties pj can reference and depend on the variables ~1, . . . , ~:j - 1. Note that we differentiate between program function- symbols and property function-symbols.

Semantics and Other Issues We have a complete and detailed semantics for the above languages that will be presented in the full version of this paper.

We note that the expression (f (every e) > for program expression e has the same meaning as the ex- pression (f e) . We will treat these two expressions as identical, even in the pattern matching used in apply- ing the inference rules given later: so the expression (f e) will match the pattern (R (every s) ) with f instantiating R and e instantiating s.

Also, we have left unresolved above the issue of how to execute a program containing an if expression that tests a nondeterministic property. This peripheral is- sue is handled in detail in the full version of the paper; here we only comment that we require the user to pro- vide a verified implementation of any nondeterminis- tic property function used in an if test in a program function definition-this task is straightforward for the examples given in this paper. We refer to a property so implemented as testable.

An Inference Algorithm Our inference algorithm accepts as input a new defini- tion (of a program function or a property function) and a background library of type theorems, and produces as output some new type theorems about the newly de- fined symbol that are then added to the background li- brary. By “type theorem” we mean a universally quan- tified formula of the form f oral1 xl:pl. - - x,:pn . p: p’ where p will typically involve the new symbol and p’ is viewed as a type or property being asserted about p. Figure 4 shows example type theorems produced in an- alyzing the example programs shown earlier. Through- out this section we assume we are analyzing a definition assigning the lambda or fix expression e to the new function symbol g, with respect to background library ,C (in particular, e will appear as a subscript on our inference relation symbols l-e and l--oe to indicate their dependence on e).

Definition Analysis An initial inference stage gen- erates very useful type theorems from a superficial

4 We must restrict recursive definitions to ensure that ev- ery fix expression accepted has a well-defined least fixed- point. This can be done for example with a simple syn- tactic restriction discussed in the longer version of this pa- per. In addition to this restriction, we require definitions of function symbols to be used in program expressions to be syntactically terminating. Checking termination is a deep problem itself, and can be addressed by methods similar to those in this paper(McAllester & Arkoudas 1996).

forall l:(a-numlist) (sort l):(a-permutation-of 1)

forall l:(a-numlist) (sort l):(a-sorted-list)

forall l:(a-list) (find-largest-clique 1): (a-clique)

I

Figure 4: Sample Output. Some theorems generated automatically using the library in figure 9.

analysis of the new definition. These theorems roughly correspond to the beta-reduction and beta-abstraction properties of the definition, processed in a form that makes them most accessible to the remainder of the algorithm-the processing breaks down the cases of top level if and one-of expressions, and handles rudimen- tary let instantiation. Definition analysis is formally the forward chaining inferential closure of the inference

DA

rules for I- shown in figure 5 along with an example theorem.

Recursive Descent Rules The main stage of infer- ence proceeds by recursive descent into the new defini- tion’s body, accumulating type (property) information along the way. This recursive descent is primarily re- sponsible for analyzing the let, if, lambda, and fix constructs in the definition. At each level of the de- scent, a basic inference engine (denoted Fe described in the next subsection) is used to generate relevant type theorems. The recursive descent phase can be viewed as an abstract interpretation(Abramsky & Han- kin 1987) (Milner 1978) program analysis.

The inference rules for I-o~ in figure 6 formally de- scribe the recursive descent analysis. These rules use some new notation. We use the notation a(p) to signify a pattern that matches p, (not p), or any monadic function applied to p, (f p). We call any expres- sion that matches a(p) a monadic variant of p. We say that a formula p’ : t is about p if p’ is a monadic variant of p. Monadic function applications have spe- cial status here because many monadic functions act to destructure their input and return some part of it (e-g- car, member-of, etc.). Finding properties of the part returned is generally useful in finding prop- erties of the original whole. Lastly, we use the nota- tion THOSE,, (s) (which we read “theorems about s provable from E”) to abbreviate the set of all formulas about s provable from C using I+,. We require that when a pattern a(p) occurs more than once in a single rule, it must match p in the same way each time: using the same monadic function, if any in each match.

The Analyze-If inference rule performs a simple case analysis, the Analyze-Lambda and Analyze-Let rules perform simple universal generalization, and the Basic- Analyze rule applies the basic inference relation I-. It

AUTOMATEDREASONING 407

Figure 5: Rules for Definition Analysis. In the rule If-DA, a reordering is suitable if it gives consequent theorems with no free variables-the rule does not fire for every suitable reordering but picks just one arbitrarily. The pattern T * s matches either Y:S or S:T, but must match the same way throughout the rule.

Start-DA If-DA

e is (lambda XI :pl - * - xn :pn B) or (fix g (lambda x1 :pl + - . xn :pn B))

DA

I- e Forall XI :pl - - a xn :p, B:(e XI.. . xn) DA

I- e Forall ~1 :pl . . * xn :pn (e XI.. . x,):B

?, Forall x1 :pl . . - xn :pn (if y; : s BI &) * t y1 : t1 * * . yn : t, is a suitable reordering of XI :pl * * * xn :pn

y Forall yl:tl . ..y.:(all-of t; s)-.-y,:t, e Bl * t

p Forall y1 : tl + . . y; : (all-of ti (not s)) * 1 * Yn : t, e

B2 *t

Let-DA One-of-DA DA

t- e Forall ~1 :pl ***xn :pn (let X:S B):t

DA

l-e Forall x1 :pl -**xn:pnx:s B:t

DA

I- e Forall x1 :pl -. - xn :pn (one-of BI.. . B,):t

?, Forall XI :pl . . - xn :pn B;:t, i = 1 . . . m

Sample theorem: Forall l:(all-of (a-list) (not ‘nil)) . (a-member-of (cdr 1)): (a-member-of 1)

Analyze-If Analyze-Let

l? = C U THM&,e (r) r = C U THMSE,~ (r) u THK5h,e (s)

r, r:s t-0, a(u1):t r, x:r be cr(s):t

r, Neg(r:s) l-oe a(u2):t x not in r or t

C be g((if r:s ul u2)):t C be cr((let x:r s)):t

Analyze-Lambda

IT = C u THkL%,e (r) r, x:r l-oOe a(B):t x,x1 not in I?, x1 not in B e is (lambda x: r B)

Basic-Analyze

c l-e s:t

cI-o Forall x1:r e fl((e xl)):[xl/x]t

c l--oe s:t

Analyze-Fix

l? = C u THMS~,e (r)

r Forall x1 :r 7

g(f xl):[xl/x]r ’ x:r I-0, B(B): I

x and x1 not in I’, XI not in B e is (fix f x:r B)

c k Forall xl:r e a((e XI)): [xl/x] 1

Figure 6: Sequent Rules for I+,. o is discussed in the text. r, s, t, u, I, and B are any property expressions. The fix and lambda rules are shown for one argument functions for readability. The notation [xJx].s stands for the expression s with every free occurrence of II: replaces by ~1. iVeg(r:s) is the formula r:(not s) if T is a program expression, and r:(a-thing) otherwise.

remains to specify how induction hypotheses for the rule Analyze-Fix are selected. Space allows only the following concise description: for each expression T which matches a(B), we compute a sequence of hy- potheses ‘Y’b, Ti . s. where each Ti is a set of proper- ties that is a subset of Ty-,. This sequence eventu- ally reaches the desired fixed-point hypothesis to use in applying the rule Analyze-Fix with a(B) = T. The seq<eiie ii defined as follbws5:

. I

7-,(-q =

Cl I

t Lcu Forallxl:pl...x,:p, 6(g Xl.. .xcn) : Int(T) 1 be ”

r;; = 7-, W-H

T,l = 7-,(T;) n T; where Int(T) is the all-of expression representing

>

the intersection of the members of Y’, and a,(g x1 . w . x~) is the result of replacing B by (g x1 . . . x,) in T. The design of the l-e relation given below ensures that the initial set To is polynomial in size, thus ensuring that this process terminates in polynomially many itera- tions. The recursive descent structure of l-o, ensures that each iteration invokes I-, polynomially often (in the size of e).

Basic Inference The basic inference relation l-e is the heart of our inference system. This relation is de- signed by the following general methodology. We start

‘Alternatively, and more practically, the hypotheses for different values of r can be computed and used together, giving a somewhat stronger inference relation. We present the simpler form here for ease in presentation.

408 KNOWLEDGE REPRESENTATION

Start Subexp Univ-Dom Wniv-Inst Dom (r) forall z:s @

sEe sEr forall x:s <p d:s, d E e

Dam W)> Dom (s) Dom (s) P/4 @ Dam ( Wxl @ >

Figure 7: Domain Construction Inference Rules for l--ee d must be a program expression, r and s can be any property expressions. The notation [d/x] s denotes s with each free occurrence of x replaced by d. We wrote s E r to mean s is a subexpression of T. The rule “Start” adds every monadic variant of an expression in e to the domain.

by introducing a new formula Dom (p) that is used only as a flag for the inference process (these formulas have no semantic content). The intended meaning for this flag is that the property p is of interest to the reasoning process if and only if Dom (p) has been asserted. We then write a set of domain construction inference rules that ensure that this flag is asserted about an appro- priately broad class of properties (usually beginning with those properties appearing directly in the prob- lem), taking care to limit this class to polynomial size. The domain construction rules for I-, are exhibited in figure 7. We denote the class of property expressions p for which Dom (p) is asserted by the symbol d. The rules in figure 7 construct an A which is polynomial in the size of the definition being analyzed plus the size of the background library6, given an assumed up- per bound on the depth of quantification in the library (i.e. the number of variables in a forall construct is bounded).

After designing the domain construction rules, we write a separate set of inference rules aimed at captur- ing the semantics of the language constructs. We write these rules with little or no concern for the computa- tional complexity of computing their closure. Finally, we restrict these rules by adding Dom () antecedents so that every property that appears in any conclusion is a monadic variant of a member of JL This restriction ensures that the resulting l-e relation can be computed in a forward-chaining manner in polynomial time in the size of the definition being analyzed plus the back- ground library. We show the domain-restricted ver- sions of the semantics capturing rules for t--e in figure 8.

Inference Algorithm Summary For each defini- tion encountered, the inference algorithm adds to the background library of type theorems those theorems

‘The type structure provided by properties makes it possible to design the algorithm to avoid using parts of the library involving types that do not hold of the expression being analyzed. For this reason we expect the complexity in practice to be polynomial in the logarithm of the library size.

Sym Trans Not-Sym

r:s Dom (d) c:d s:t d:(not e)

d:c r:t e:(not d)

One-Qfl One-Of2 Under-All-Of

r:(one-of s t) s:r, t:r r:(not s)

Dom ((all-of s t)) Dom ((one-of s t)) r:s, r:t

r:t (one-of s t):r r:(all-of s t)

asic-One-Of Basic-All-Of Selectors1 Dom ((one-of s t)) Dom ((all-of s t)) Dom ((cons c d))

s:(one-of s t) (all-of s t):s c:(car (cons c d)) t:(one-of s t) (all-of s t):t d:(cdr (cons c d))

Selectors2 Always’ Strictness Monotone1 Dom (r) r:(cons s t)

yyf 4) s:t Dam(s) : r:(f 4

(car r):s s:s, 1:s (f +J- Dam ((f w

(cclr r):t s:(a-thing) r:(f t)

Monotone2 Every-One-Of Not-One-Of

r:(f (every s)) s:t r:(f (every t)) r:(not r:(f (every t)) u:(one-of s t) (one-of s t)) Dom (f (every s)) Dom (f (every u))

r:(not s) r:(f (every s)) r:(f (every u)) r:(not t)

Figure 8: Basic Inference Rules for I-,. c and d must be program expressions. r, s, t, and u can be any property expressions. f can be any function symbol, constructor or selector. We show rules for one-of and all-of for the two argument case and applications for one argument for readability.

forall l:(a-list) . 1: (a-permutation-of 1)

forall l:(a-list) . (a-permutation-of (a-permutation-of 1)): (a-permutation-of 1)

forall n:(a-thing) D n:(a-neighbor-of (every (neighbor-of n>>>

forall ~:(a-number) y:(all-of (a-number) (not (>= x1>> .

x:(>= Jr)

forall l:(all-of (a-sorted-list) (not 'nil>)

x: (>= (car 1)) D x: (>= (every (a-member-of 1)))

Figure 9: Library Theorems. The theorems needed from the user or the property library.

AUTOMATED REASONING 409

implied by either r, or be, each of which is polyno- mial time computable in the size of the new definition body e plus the size of the background library. Each occurrence of the e in each theorem is replaced by the new symbol being defined before adding to the library.

Background Library Needed For Examples The insertion sort and clique finding examples given above rely on the presence in the background library of a few theorems that this algorithm does not find on its own. These theorems are shown in figure 9. These are not theorems about insertion sort or clique find- ing, but rather theorems about the properties involved. The need for these theorems reflects that this algo- rithm needs a deeper understanding of properties such as a-permutation-of than that it attains by read- ing the definition in order to infer that property for some programs. Most theorems needed are automati- cally inferred-one such theorem was shown in figure 5. Also, the library theorems in our examples concern only the definitions in the type library, not the pro- grams being analyzed--all the theorems needed about the target programs are automatically inferred. Never- theless, the library theorems needed point up opportu- nities to strengthen the algorithm we have described- by analyzing the proofs of these theorems to determine which aspects fail to be discovered automatically we may discover new inference principles which can use- fully be added to a polynomial time inference proce- dure.

Conclusions We have presented a novel language for defining ar- bitrary properties of computer programs. The repre- sentational features of this property language were se- lected to enlarge the set of polynomial-time checkable property-program relationships. We have presented, in as much detail as space allows, an inference pro- cedure which can infer interesting properties of sim- ple computer programs in the context of a library of background knowledge, and guarantees completion in polynomial time in the size of its input.

We do not claim that the algorithm we have pre- sented is distinguished among similar algorithms. We intend this algorithm as an example of what may be ac- complished in this area. We desire the construction of stronger similar algorithms, together with a large cor- pus of example program-property theorems on which to test such algorithms. These algorithms can be seen as roughly analogous to the human notion of “obvi- ous consequence” -what consequences can be inferred quickly? The human “obviousness engine” works with a very expressive language, is naturally incomplete, re- turns its answers quickly, and has no apparent clean characterization of the set of conclusions it finds. We propose the study of the machine counterpart to this human notion wherein we require rapid termination and refuse to limit expressiveness simply to get a clean

characterization of the inferrable properties.

References Abramsky, S., and Hankin, C., eds. 1987. Abstract Interpretation of Declarative Languages. Ellis Hor- wood. Brachman, R., and Schmolze, J. 1985. An overview of the kl-one knowledge representation system. Com- putational Intelligence 9(2):171-216. McAllester, D., and Arkoudas, K. 1996. Walther recursion. In 13th International Conference on Auto- mated Deduction. McAllester, D., and Givan, R. 1992. Natural language syntax and first order inference. Artificial Intelligence 56:1-20. ftp.ai.mit.edu:/pub/users/dam/aij 1 .ps. McAllester, D., and Givan, R. 1993. Taxonomic syn- tax for first order inference. JACM 40(2):246-283. ftp.ai.mit.edu:/pub/users/dam/jacml .ps. McCarthy, J. 1967. A basis for a mathematical the- ory of computation. In Braffort, P., and Hirschberg, D., eds., Computer Programing and Formal Systems. North-Holland. Milner, R. 1978. A theory of type polymorphism in programming. JCSS 17:348-375. Nebel, B. 1990. Terminological reasoning is inherently intractable. Artificial Intelligence 43:235-249. Nelson, G., and Oppen, D. 1980. Fast decision proce- dures based on congruence closure. JACM 27(2):356. Owre, S.; Rushby, J.; and Shankar, N. 1992. Pvs: A prototype verification system. In 1 lth International Conference on Automated Deduction, 748-752.

410 KNOWLEDGE REPRESENTATION