This preview shows pages 1–3. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.
View Full Document
Unformatted text preview: 98127Specifications, Programs, and Total CorrectnessEric C.R. HehnerUniversity of TorontoAbstractThis paper argues the following positions: that a formal specification is a boolean expression, thata program is a specification, and that total correctness is a poor choice of semantics.Keywords: specification; program; total correctnessI have three opinions to present: first, that a formal specification is a boolean expression; second,that a program is a formal specification; and third, that total correctness is a mistake. I amdiscussing what are sometimes called “formal methods” of programming, but I am not debating theusefulness of formal methods to programmers; that debate has been well aired here and elsewhere.I am debating the direction formal methods research has taken. My concern is first to find asatisfactory theoretical foundation for programming, and ultimately to create useful tools to aidprogrammers.Formal methods researchers have invented a fascinating variety of formalisms, and have probedinto their far corners, finding some esoteric things, such as havoc and angelic nondeterminism.Although this work is theoretically interesting, I believe we are now in a position to say in a simpleand clear way, independent of all specialpurpose notations, what constitutes a formalspecification, and what is the relationship between specifications and programs.Opinion: a formal specification is a boolean expression.By “formal specification” I mean some kind of mathematical expression. I shall argue that the bestkind of expression to use as a formal specification is a boolean expression rather than a set orpredicate or pair of predicates or predicate transformer or any other kind of mathematicalexpression. For the purpose of arguing this opinion, it does not matter whether we are specifyingcomputations, cars, or anything else.First a word on my terminology. By “boolean expression” I mean an expression that evaluates to aboolean when values are provided for its (global or free) variables. I do not mean to be restrictivein the allowed operators; quantifiers are welcome. For example,x>y∧(5z· y= f(z))is a boolean expression. I allow variables of any type, and any operators and functions.Terminology and notations that pertain to an application are encouraged. Sometimes it is helpful toinvent a notation specifically for use in one particular expression.By “predicate” I mean a function that results in a boolean when applied to values in its domain.For example,λy· y>5I still say “predicate” when there are global variables, as inλy· y>xBy “relation” I mean a function that results in a predicate when applied to values in its domain.For example,λx· λy· y>xwhich may also be written as a function of two variablesλx, y· y>xI'm not concerned here whether variables are strongly, weakly, or untyped; choose yourfavorite. And I'm not concerned here with definedness, completeness, computability, or order ofevaluation. And I don't distinguish between an expression that evaluates to a boolean and a...
View
Full
Document
This note was uploaded on 04/18/2011 for the course COMPUTER S 1111 taught by Professor Name during the Spring '05 term at MIT.
 Spring '05
 Name

Click to edit the document details