Predicate transformer semantics

This is an old revision of this page, as edited by Boulme (talk | contribs) at 12:48, 14 May 2010 (Examples of predicate transformers). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Predicate transformer semantics is a reformulation of Floyd–Hoare logic. While Hoare logic was originally presented as a deductive system, predicate transformer semantics (either by weakest-preconditions or by strongest-postconditions see below) give an effective algorithm to reduce the problem verifying a Hoare triple to the problem of proving a first-order formula.

Predicate transformer semantics has been introduced by Dijkstra in its seminal paper "Guarded commands, nondeterminacy and formal derivation of programs". It is a method for defining the semantics of an imperative programming language by assigning to each command in the language a corresponding predicate transformer: a predicate transformer is a total function mapping between two predicates on the state space of a program. Actually, in Guarded commands, Dijkstra uses only one kind of predicate transformers: the well-known weakest preconditions (see below).

Weakest preconditions

Definition

Given a S denotes a statement, the weakest-precondition of S is a function mapping any postcondition R (R denotes thus a predicate on the space of states) to a precondition. Actually, the result of this function, denoted  , is the "weakest" precondition on the initial state ensuring that execution of S terminates in a final state satisfying R. More formally, a given Hoare triple   is provable in Hoare logic for total correctness iff the first-order predicate below is universally valid (e.g. for all possible values of the space of states):

 

Formally, weakest-preconditions are defined recursively over the abstract syntax of statements.

Skip

 

Abort

  

Assignment

We give below two equivalent weakest-preconditions for the assignment statement (in these formulas,   is a copy of R where fresh occurrences of x are replaced by E):

  • version 1:
   where y is a fresh variable (representing the final value of variable x). 
  • version 2:
   

The first version avoids a potential duplication of E in R, whereas the second version is simpler when there is at most a single occurrence of x in E. The first version reveals also a deep duality between weakest-precondition and strongest-postcondition (see below).

An example of a valid calculation of wp (using version 2) for assignments with integer valued variable x is:

 

This means that in order for the "post-condition" x > 10 to be true after the assignment, the "pre-condition" x > 15 must be true before the assignment. This is also the "weakest pre-condition", in that it is the "weakest" restriction on the value of x which makes x > 10 true after the assignment.

Sequence

  

As example:

 

Other examples of predicate transformers

Weakest liberal precondition

An important variant of the weakest precondition is the weakest liberal precondition  , which yields the weakest condition under which S either does not terminate or establishes R. It therefore differs from wp in not guaranteeing termination. Hence it corresponds to Hoare logic in partial correctness.

Strongest postcondition

Given S a statement and R a precondition (a predicate on the initial state), then   is the strongest-postcondition: it implies any postcondition satisfied by the final state of the execution of S, for any initial state statisfying R. For example, on assignment we have:

  where   is fresh.

Above, the logical variable   represents the initial value of variable  . Hence,

 

Win and sin predicate transformers

Leslie Lamport has suggested win and sin as predicate transformers for concurrent programming.

Applications

  • Unlike many other semantic formalisms, predicate transformer semantics was not designed as an investigation into foundations of computation. Rather, it is intended to provide programmers with a methodology to develop their programs as "correct by construction" in an "calculation style". This style was advocated by Dijkstra and others, and also developed further in a higher order logic setting by R.-J. Back in the Refinement Calculus. It has been mechanized in B-Method.

Dijkstra also defined alternative (if) and repetitive (do) constructs as well as a composition operator (;) using wp. The alternative and repetitive constructs used guarded commands to influence execution. Because of the rules he imposed on the definition of wp, both constructs allow for non-deterministic execution if the guards in the commands are non disjoint.

See also

References