CSE Winter 2008 Introduction to Program Verification February 5 calculating with simplify

review the simplify algorithm simplify(Expr) = Result if path_arg(Path, Expr) = Lhs, % (there is a path in Expr to the sub-expression LHS) and Lhs ->> Rhs, and Modified = change_path_arg(Path, Expr, Rhs), and Result = simplify(Modified) otherwise simplify(Expr) = Expr.

in English -- Result is the result of simplifying Expr if there is a path in Expr to a subterm Lhs, and there is a rule that Lhs ->> Rhs, and Modified is the term Expr with the Lhs subterm replaced by Rhs, otherwise Result is the input Expr simplify is an interpreter for "rewrite programs" (rules)

how do we enter rules? |: theory(file). looks for a file named file.simp |: theory('file.simp'). or |: assert(( rule )). adds the rule at the end of the current list of rules

playing with simplify indigo 301 % simplify Version 1.4.2SWI, January 6, 2007 |:x > 0 implies a+a=a*2. x>0 implies a+a=a*2 ->> 0<x implies a+a=a*2 Can we simplify further? try using a theory? trace ?

review: use simplify to do calculations on abstract datatypes - symbolically we represent everything by expressions (terms) — not objects example: calculate on stacks, using expressions to represent the stack objects evaluation of expressions is symbolic hence general: X-X ->> 0 means that X-X = 0 for all (symbolic) values of X.

conditional rules conditional rules evaluate relations and numerical expressions left ->> right :- condition applies if condition can be shown to simplify to true, X > Y ->> true :- X > Y. condition is true if X, Y are numbers and X is less than Y. conditional rules use a built-in evaluator, assigned, to evaluate functions in numerical expressions type information such as integer(X)can be used in a conditional rule.

conditional example |:assert((M*N ->> Product :- Product assigned M*N)). |: 2*3. 2*3 ->> 6 Check use of assigned in /cs/course/3341/arithmetic.simp.

developing rules to get a proof exercise 4.1 |:(a + b = b + a) implies a > false find a general rule to complete the proof. (replace arithmetic variables (lower-case) with pattern (upper- case) variables)

exercise 4.3, page 12. |: assert((0*X ->> 0)). |: x*y*0. x*y*0 ->> 0 |: x*0*y. x*y*0 ->> 0 reconstruct the rules which achieve the simplifications in Sec. 4.4

4.4 |:2*q+q*((a+8-a)-7) + q. 2*q+q* (8-7)+q 2*q+q*1+q 2*q+q+q 2*q+q*2 q*4 2*q+q* (a+8-a-7)+q ->> q*4

Ch. 5.1: abstract data types now have the tools for verifying some algebraic calculations given the right theory file, we can do symbolic calculation on abstract datatypes ADTs are characterized by interrelated equations "if it quacks like a duck..." Leibnitz law ?

start with stacks push makes a new stack out of a stack argument and a data item pop makes a new smaller stack from a stack argument top extracts a data item from a stack stacks are actually isomorphic to a simple kind of list (CONS X List) = add X to the front of List = push X on the stack List specific stacks (constants) represented by expressions using push example: push(z, push(b, nil)) push is the constructor for this datatype. treat these as functors of terms push(data, stack)

stack computers examples: HP calculators a stack computer will have stack operations or functions defined from push, pop, and top languages: Forth, Factor Java VM -- see exercise 5.3 examples on p. 49

verification scenario: evaluate an ADT expression context: ADT defined by axioms in the form of identities method: input ADT axioms and definitions to the simplify tool in the form of simplification rules; input an expression to be checked and see if it simplifies to the expected result. background: mathematical simplification rules. The correctness of the evaluation is relative to the assumed correctness of the simplification rules and the correctness of the ADT axioms and definitions.

stack calculations stack function definitions are equations, turn them into rewrite rules and use them to do symbolic calculation on stacks definitions of plus, times, etc. describe a stack-based arithmetic calculator

unspecified implementation Example: over(S) = push(top(pop(S)), S) What does over(S) do? does it really work by popping S, and pushing the top element of this new stack onto the original S? implementation is not specified (that's why the datatype is abstract)

what happens if we do an illegal operation? e. g. pop(pop(push(a, nil))) can we use simplify to detect illegal operations?

a very simple verification scenario prove (by symbolic calculation) that a certain sequence of operations on an abstract datatype computes a particular mathematical function. doubling example: |: theory('stack.simp'). |: plus(dup(push(a, nil))). plus(dup(push(a,nil))) ->> push(a+a,nil)

correctness relies on correctness? correctness of our verification scenario for expression evaluation rests on correctness of theory files doesn't this invalidate the whole idea of verification? No, theory (.simp) files are general should be highly re-usable theories become quickly "bug-free" much easier to check than code evolve through use to become more comprehensive

verifying a Java stack machine program what does [Ingram, 1997] refer to? what does the manual tell you about a bytecode? pop=87 Stack:..., VAL ->... pop2=88 Stack:..., VAL1, VAL2 ->... dup=89 Stack:..., V ->..., V, V what would a verification scenario for the JVM look like?

JVM scenario title: verify JVM bytecode sequence method: input bytecode definitions as rewrite rules, input bytecode sequence, perhaps as a list [..,..... ] and initial stack (as an expression) to simplify confirm the simplification yields desired result. background: stack axioms, stack operation definitions, and perhaps theorems; additional rewrite rules for processing a list (see Forth exercise)

queues a new ADT: queues Exercise (a) and (b)