CS 641 meeting -*- Outline -*-

* discussion of Hoare's paper: An Axiomatic Basis for Computer Programming
	(CACM, 10(12):576-580,583, 1969)

	See the homework, on which the discussion is based

** section 2
	a. other axioms might be induction, axioms for <, >, =, ...
	b. nonnegative integers are less complex,
		for example associativity only holds for all models of
		finiteness for naturals
	   have additional axioms on board

** section 3
	I also briefly discussed Floyd's method
		by drawing flow chart of program,
		showing where the assertions go (on each edge),
		and showing what has to be proved.

	c. constant functions aren't interesting.  sorting is an example
	d. discuss

	e. it's valid as long as they match
	f. seems to be a good simplification, but doesn't help, e.g., in C++:
		cout << 3 << endl;
	   a type system might help

	g. (do quickly) also assumes predicate calculus
	   |- R ==> S means the implication is provable.

	h. abstract syntax
	   discuss the writing questions
	i. discuss

	j. the issue is (relative) completeness
	k. yes, its both valid and provable.
		def: a triple Q {S} R is valid if S is started in a state
			that satisfies Q and terminates, then it terminates
			in a state satisfying R.
		def: a triple Q {S} R is provable iff it follows
			from Hoare's rules.
	   this example is both valid and provable:
		valid because loop never terminates!
		def: a program S is partially correct wrt to Q {S} R
			iff Q {S} R is valid.
		proof:  |- true /\ 3<4 {x := x + 1} true   	(D0)
			|- true {while 3<4 do x:= x+1} ~(3<4)   (D3)
			|- ~(3<4) ==> 3=4			(arithmetic)
			|- true {while 3<4 do x:= x+1} 3=4	(D1)

	l. maybe show annotated proof, or work backwards (a la Dijkstra)
	m. anyone do this?
	n. discuss

** section 4
	o. seems to be a fruitful instance of separation of concerns
	   discuss
	p. discuss
	   quality perspective: errors in product shipped can be infinitely
		expensive (e.g., reviewer buys faulty one)
	   testing still needed, debugging is expensive
	q. may be impractical for portability?
	   meant annotation for specifying programs, not documenting them

** section 6
	r. discuss
	   simplicity
	   designing language that doesn't have features (like side-effects
		in expressions) that make verification difficult

** section 7
	t. ask students to summarize
	u. related to structured programming in that it only has to do with
		structured constructs and this style only works for them
		(compare Floyd)
	v. ghost variables
	w. in Hoare logic, only one way to prove things (limiting)