{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

E.C.R. Hehner_Specifications, Programs, and Total Correctness

E.C.R. Hehner_Specifications, Programs, and Total Correctness

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
98-12-7 0 Specifications, Programs, and Total Correctness Eric C.R. Hehner University of Toronto Abstract This paper argues the following positions: that a formal specification is a boolean expression, that a program is a specification, and that total correctness is a poor choice of semantics. Keywords : specification; program; total correctness I 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 am discussing what are sometimes called “formal methods” of programming, but I am not debating the usefulness 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 a satisfactory theoretical foundation for programming, and ultimately to create useful tools to aid programmers. Formal methods researchers have invented a fascinating variety of formalisms, and have probed into 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 simple and clear way, independent of all special-purpose notations, what constitutes a formal specification, 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 best kind of expression to use as a formal specification is a boolean expression rather than a set or predicate or pair of predicates or predicate transformer or any other kind of mathematical expression. For the purpose of arguing this opinion, it does not matter whether we are specifying computations, cars, or anything else. First a word on my terminology. By “boolean expression” I mean an expression that evaluates to a boolean when values are provided for its (global or free) variables. I do not mean to be restrictive in the allowed operators; quantifiers are welcome. For example, x > y ( 5 z · y = f ( z )) is a boolean expression. I allow variables of any type, and any operators and functions.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Terminology and notations that pertain to an application are encouraged. Sometimes it is helpful to invent 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 >5 I still say “predicate” when there are global variables, as in λ y · y > x By “relation” I mean a function that results in a predicate when applied to values in its domain. For example, λ x · λ y · y > x which may also be written as a function of two variables λ x , y · y > x I'm not concerned here whether variables are strongly-, weakly-, or un-typed; choose your favorite. And I'm not concerned here with definedness, completeness, computability, or order of evaluation.
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}