CSE 3341.03 Winter 2008Introduction to Program VerificationFebruary 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) • otherwisesimplify(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, otherwiseResult 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 < b < 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 • topextracts 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 frompush, 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 5.3 -- (a) and (b)
