Some Advice for Working on Exercises:

• Most of the Coq proofs we ask you to do are similar to proofs that we've provided. Before starting to work on exercises problems, take the time to work through our proofs (both informally and in Coq) and make sure you understand them in detail. This will save you a lot of time.
• The Coq proofs we're doing now are sufficiently complicated that it is more or less impossible to complete them by random experimentation or "following your nose." You need to start with an idea about why the property is true and how the proof is going to go. The best way to do this is to write out at least a sketch of an informal proof on paper — one that intuitively convinces you of the truth of the theorem — before starting to work on the formal one. Alternately, grab a friend and try to convince them that the theorem is true; then try to formalize your explanation.
• Use automation to save work! The proofs in this chapter can get pretty long if you try to write out all the cases explicitly.

Behavioral Equivalence

In an earlier chapter, we investigated the correctness of a very simple program transformation: the optimize_0plus function. The programming language we were considering was the first version of the language of arithmetic expressions — with no variables — so in that setting it was very easy to define what it means for a program transformation to be correct: it should always yield a program that evaluates to the same number as the original. To talk about the correctness of program transformations for the full Imp language, in particular assignment, we need to consider the role of variables and state.

Definitions

For aexps and bexps with variables, the definition we want is clear: Two aexps or bexps are behaviorally equivalent if they evaluate to the same result in every state.

Here are some simple examples of equivalences of arithmetic and boolean expressions.

For commands, the situation is a little more subtle. We can't simply say "two commands are behaviorally equivalent if they evaluate to the same ending state whenever they are started in the same initial state," because some commands, when run in some starting states, don't terminate in any final state at all! What we need instead is this: two commands are behaviorally equivalent if, for any given starting state, they either (1) both diverge or (2) both terminate in the same final state. A compact way to express this is "if the first one terminates in a particular state then so does the second, and vice versa."

Simple Examples

For examples of command equivalence, let's start by looking at some trivial program transformations involving SKIP:

Exercise: 2 stars, standard (skip_right)

Prove that adding a SKIP after a command results in an equivalent program

Of course, no (human) programmer would write a conditional whose guard is literally true. But they might write one whose guard is equivalent to true: Theorem: If b is equivalent to BTrue, then TEST b THEN c₁ ELSE c₂ FI is equivalent to c₁. Proof:

• (→) We must show, for all st and st', that if st =[ TEST b THEN c₁ ELSE c₂ FI ]⇒ st' then st =[ c₁ ]⇒ st'.
  Proceed by cases on the rules that could possibly have been used to show st =[ TEST b THEN c₁ ELSE c₂ FI ]⇒ st', namely E_IfTrue and E_IfFalse.
  • Suppose the final rule in the derivation of st =[ TEST b THEN c₁ ELSE c₂ FI ]⇒ st' was E_IfTrue. We then have, by the premises of E_IfTrue, that st =[ c₁ ]⇒ st'. This is exactly what we set out to prove.
  • On the other hand, suppose the final rule in the derivation of st =[ TEST b THEN c₁ ELSE c₂ FI ]⇒ st' was E_IfFalse. We then know that beval st b = false and st =[ c₂ ]⇒ st'.
    Recall that b is equivalent to BTrue, i.e., forall st, beval st b = beval st BTrue. In particular, this means that beval st b = true, since beval st BTrue = true. But this is a contradiction, since E_IfFalse requires that beval st b = false. Thus, the final rule could not have been E_IfFalse.
• (<-) We must show, for all st and st', that if st =[ c₁ ]⇒ st' then st =[ TEST b THEN c₁ ELSE c₂ FI ]⇒ st'.
  Since b is equivalent to BTrue, we know that beval st b = beval st BTrue = true. Together with the assumption that st =[ c₁ ]⇒ st', we can apply E_IfTrue to derive st =[ TEST b THEN c₁ ELSE c₂ FI ]⇒ st'. ☐

Here is the formal version of this proof:

Exercise: 2 stars, standard, recommended (TEST_false)

Exercise: 2 stars, advanced, optional (WHILE_false_informal)

Write an informal proof of WHILE_false. (* FILL IN HERE *)
☐ To prove the second fact, we need an auxiliary lemma stating that WHILE loops whose guards are equivalent to BTrue never terminate. Lemma: If b is equivalent to BTrue, then it cannot be the case that st =[ WHILE b DO c END ]⇒ st'. Proof: Suppose that st =[ WHILE b DO c END ]⇒ st'. We show, by induction on a derivation of st =[ WHILE b DO c END ]⇒ st', that this assumption leads to a contradiction. The only two cases to consider are E_WhileFalse and E_WhileTrue, the others are contradictory.

• Suppose st =[ WHILE b DO c END ]⇒ st' is proved using rule E_WhileFalse. Then by assumption beval st b = false. But this contradicts the assumption that b is equivalent to BTrue.
• Suppose st =[ WHILE b DO c END ]⇒ st' is proved using rule E_WhileTrue. We must have that:
  1. beval st b = true, 2. there is some st₀ such that st =[ c ]⇒ st₀ and st₀ =[ WHILE b DO c END ]⇒ st', 3. and we are given the induction hypothesis that st₀ =[ WHILE b DO c END ]⇒ st' leads to a contradiction,
  We obtain a contradiction by 2 and 3. ☐

Exercise: 2 stars, standard, optional (WHILE_true_nonterm_informal)

Explain what the lemma WHILE_true_nonterm means in English. (* FILL IN HERE *)
☐

Exercise: 2 stars, standard, recommended (WHILE_true)

Prove the following theorem. Hint: You'll want to use WHILE_true_nonterm here.

Exercise: 2 stars, standard, optional (seq_assoc)

Exercise: 2 stars, standard, recommended (assign_aequiv)

Properties of Behavioral Equivalence

We next consider some fundamental properties of program equivalence.

Behavioral Equivalence Is an Equivalence

First, we verify that the equivalences on aexps, bexps, and coms really are equivalences — i.e., that they are reflexive, symmetric, and transitive. The proofs are all easy.

Behavioral Equivalence Is a Congruence

Less obviously, behavioral equivalence is also a congruence. That is, the equivalence of two subprograms implies the equivalence of the larger programs in which they are embedded:

aequiv a1 a1'
cequiv (x ::= a1) (x ::= a1')

cequiv c1 c1'
cequiv c2 c2'
cequiv (c1;;c2) (c1';;c2')

... and so on for the other forms of commands. (Note that we are using the inference rule notation here not as part of a definition, but simply to write down some valid implications in a readable format. We prove these implications below.) We will see a concrete example of why these congruence properties are important in the following section (in the proof of fold_constants_com_sound), but the main idea is that they allow us to replace a small part of a large program with an equivalent small part and know that the whole large programs are equivalent without doing an explicit proof about the non-varying parts — i.e., the "proof burden" of a small change to a large program is proportional to the size of the change, not the program.

The congruence property for loops is a little more interesting, since it requires induction. Theorem: Equivalence is a congruence for WHILE — that is, if b₁ is equivalent to b₁' and c₁ is equivalent to c₁', then WHILE b₁ DO c₁ END is equivalent to WHILE b₁' DO c₁' END. Proof: Suppose b₁ is equivalent to b₁' and c₁ is equivalent to c₁'. We must show, for every st and st', that st =[ WHILE b₁ DO c₁ END ]⇒ st' iff st =[ WHILE b₁' DO c₁' END ]⇒ st'. We consider the two directions separately.

• (→) We show that st =[ WHILE b₁ DO c₁ END ]⇒ st' implies st =[ WHILE b₁' DO c₁' END ]⇒ st', by induction on a derivation of st =[ WHILE b₁ DO c₁ END ]⇒ st'. The only nontrivial cases are when the final rule in the derivation is E_WhileFalse or E_WhileTrue.
  • E_WhileFalse: In this case, the form of the rule gives us beval st b₁ = false and st = st'. But then, since b₁ and b₁' are equivalent, we have beval st b₁' = false, and E_WhileFalse applies, giving us st =[ WHILE b₁' DO c₁' END ]⇒ st', as required.
  • E_WhileTrue: The form of the rule now gives us beval st b₁ = true, with st =[ c₁ ]⇒ st'0 and st'0 =[ WHILE b₁ DO c₁ END ]⇒ st' for some state st'0, with the induction hypothesis st'0 =[ WHILE b₁' DO c₁' END ]⇒ st'.
    Since c₁ and c₁' are equivalent, we know that st =[ c₁' ]⇒ st'0. And since b₁ and b₁' are equivalent, we have beval st b₁' = true. Now E_WhileTrue applies, giving us st =[ WHILE b₁' DO c₁' END ]⇒ st', as required.
• (<-) Similar. ☐

Exercise: 3 stars, standard, optional (CSeq_congruence)

Exercise: 3 stars, standard (CIf_congruence)

Exercise: 3 stars, advanced, optional (not_congr)

We've shown that the cequiv relation is both an equivalence and a congruence on commands. Can you think of a relation on commands that is an equivalence but not a congruence?

Program Transformations

A program transformation is a function that takes a program as input and produces some variant of the program as output. Compiler optimizations such as constant folding are a canonical example, but there are many others. A program transformation is sound if it preserves the behavior of the original program.

The Constant-Folding Transformation

An expression is constant when it contains no variable references. Constant folding is an optimization that finds constant expressions and replaces them by their values.

Note that this version of constant folding doesn't eliminate trivial additions, etc. — we are focusing attention on a single optimization for the sake of simplicity. It is not hard to incorporate other ways of simplifying expressions; the definitions and proofs just get longer.

Not only can we lift fold_constants_aexp to bexps (in the BEq and BLe cases); we can also look for constant boolean expressions and evaluate them in-place.

To fold constants in a command, we apply the appropriate folding functions on all embedded expressions.

Soundness of Constant Folding

Now we need to show that what we've done is correct. Here's the proof for arithmetic expressions:

Exercise: 3 stars, standard, optional (fold_bexp_Eq_informal)

Here is an informal proof of the BEq case of the soundness argument for boolean expression constant folding. Read it carefully and compare it to the formal proof that follows. Then fill in the BLe case of the formal proof (without looking at the BEq case, if possible). Theorem: The constant folding function for booleans, fold_constants_bexp, is sound. Proof: We must show that b is equivalent to fold_constants_bexp b, for all boolean expressions b. Proceed by induction on b. We show just the case where b has the form BEq a₁ a₂. In this case, we must show There are two cases to consider:

• First, suppose fold_constants_aexp a₁ = ANum n₁ and fold_constants_aexp a₂ = ANum n₂ for some n₁ and n₂.
  In this case, we have
      fold_constants_bexp (BEq a₁ a₂)
    = if n₁ =? n₂ then BTrue else BFalse
  and
      beval st (BEq a₁ a₂)
    = (aeval st a₁) =? (aeval st a₂).
  By the soundness of constant folding for arithmetic expressions (Lemma fold_constants_aexp_sound), we know
      aeval st a₁
    = aeval st (fold_constants_aexp a₁)
    = aeval st (ANum n₁)
    = n₁
  and
      aeval st a₂
    = aeval st (fold_constants_aexp a₂)
    = aeval st (ANum n₂)
    = n₂,
  so
      beval st (BEq a₁ a₂)
    = (aeval a₁) =? (aeval a₂)
    = n₁ =? n₂.
  Also, it is easy to see (by considering the cases n₁ = n₂ and n₁ ≠ n₂ separately) that
      beval st (if n₁ =? n₂ then BTrue else BFalse)
    = if n₁ =? n₂ then beval st BTrue else beval st BFalse
    = if n₁ =? n₂ then true else false
    = n₁ =? n₂.
  So
      beval st (BEq a₁ a₂)
    = n₁ =? n₂.
    = beval st (if n₁ =? n₂ then BTrue else BFalse),
  as required.
• Otherwise, one of fold_constants_aexp a₁ and fold_constants_aexp a₂ is not a constant. In this case, we must show
      beval st (BEq a₁ a₂)
    = beval st (BEq (fold_constants_aexp a₁)
                    (fold_constants_aexp a₂)),
  which, by the definition of beval, is the same as showing
      (aeval st a₁) =? (aeval st a₂)
    = (aeval st (fold_constants_aexp a₁)) =?
              (aeval st (fold_constants_aexp a₂)).
  But the soundness of constant folding for arithmetic expressions (fold_constants_aexp_sound) gives us
    aeval st a₁ = aeval st (fold_constants_aexp a₁)
    aeval st a₂ = aeval st (fold_constants_aexp a₂),
  completing the case. ☐

(Doing induction when there are a lot of constructors makes specifying variable names a chore, but Coq doesn't always choose nice variable names. We can rename entries in the context with the rename tactic: rename a into a₁ will change a to a₁ in the current goal and context.)

Soundness of (0 + n) Elimination, Redux

Exercise: 4 stars, advanced, optional (optimize_0plus)

Recall the definition optimize_0plus from the Imp chapter of Logical Foundations: Note that this function is defined over the old aexps, without states. Write a new version of this function that accounts for variables, plus analogous ones for bexps and commands: Prove that these three functions are sound, as we did for fold_constants_*. Make sure you use the congruence lemmas in the proof of optimize_0plus_com — otherwise it will be long! Then define an optimizer on commands that first folds constants (using fold_constants_com) and then eliminates 0 + n terms (using optimize_0plus_com).

• Give a meaningful example of this optimizer's output.
• Prove that the optimizer is sound. (This part should be very easy.)

Proving Inequivalence

Suppose that c₁ is a command of the form X ::= a₁;; Y ::= a₂ and c₂ is the command X ::= a₁;; Y ::= a₂', where a₂' is formed by substituting a₁ for all occurrences of X in a₂. For example, c₁ and c₂ might be: Clearly, this particular c₁ and c₂ are equivalent. Is this true in general? We will see in a moment that it is not, but it is worthwhile to pause, now, and see if you can find a counter-example on your own. More formally, here is the function that substitutes an arithmetic expression u for each occurrence of a given variable x in another expression a:

And here is the property we are interested in, expressing the claim that commands c₁ and c₂ as described above are always equivalent.

Sadly, the property does not always hold — i.e., it is not the case that, for all x₁, x₂, a₁, and a₂, To see this, suppose (for a contradiction) that for all x₁, x₂, a₁, and a₂, we have Consider the following program: Note that where st₁ = (Y !-> 1 ; X !-> 1). By assumption, we know that so, by the definition of cequiv, we have But we can also derive where st₂ = (Y !-> 2 ; X !-> 1). But st₁ ≠ st₂, which is a contradiction, since ceval is deterministic! ☐

Exercise: 4 stars, standard, optional (better_subst_equiv)

The equivalence we had in mind above was not complete nonsense — it was actually almost right. To make it correct, we just need to exclude the case where the variable X occurs in the right-hand-side of the first assignment statement.

Using var_not_used_in_aexp, formalize and prove a correct version of subst_equiv_property.

Extended Exercise: Nondeterministic Imp

As we have seen (in theorem ceval_deterministic in the Imp chapter), Imp's evaluation relation is deterministic. However, non-determinism is an important part of the definition of many real programming languages. For example, in many imperative languages (such as C and its relatives), the order in which function arguments are evaluated is unspecified. The program fragment might call f with arguments (1, 0) or (1, 1), depending how the compiler chooses to order things. This can be a little confusing for programmers, but it gives the compiler writer useful freedom. In this exercise, we will extend Imp with a simple nondeterministic command and study how this change affects program equivalence. The new command has the syntax HAVOC X, where X is an identifier. The effect of executing HAVOC X is to assign an arbitrary number to the variable X, nondeterministically. For example, after executing the program: the value of Y can be any number, while the value of Z is twice that of Y (so Z is always even). Note that we are not saying anything about the probabilities of the outcomes — just that there are (infinitely) many different outcomes that can possibly happen after executing this nondeterministic code. In a sense, a variable on which we do HAVOC roughly corresponds to an uninitialized variable in a low-level language like C. After the HAVOC, the variable holds a fixed but arbitrary number. Most sources of nondeterminism in language definitions are there precisely because programmers don't care which choice is made (and so it is good to leave it open to the compiler to choose whichever will run faster). We call this new language Himp (``Imp extended with HAVOC'').

To formalize Himp, we first add a clause to the definition of commands.

Exercise: 2 stars, standard (himp_ceval)

Now, we must extend the operational semantics. We have provided a template for the ceval relation below, specifying the big-step semantics. What rule(s) must be added to the definition of ceval to formalize the behavior of the HAVOC command?

As a sanity check, the following claims should be provable for your definition:

Let's apply this definition to prove some nondeterministic programs equivalent / inequivalent.

Exercise: 3 stars, standard (havoc_swap)

Are the following two programs equivalent?

If you think they are equivalent, prove it. If you think they are not, prove that.

If you think they are equivalent, then prove it. If you think they are not, then prove that. (Hint: You may find the assert tactic useful.)

Intuitively, p₁ and p₂ have the same termination behavior: either they loop forever, or they terminate in the same state they started in. We can capture the termination behavior of p₁ and p₂ individually with these lemmas:

Additional Exercises

Exercise: 4 stars, standard, optional (for_while_equiv)

This exercise extends the optional add_for_loop exercise from the Imp chapter, where you were asked to extend the language of commands with C-style for loops. Prove that the command: is equivalent to:

For example, the program approximates c₂ = X ::= 1, but c₂ does not approximate c₁ since c₁ does not terminate when X = 0 but c₂ does. If two programs approximate each other in both directions, then they are equivalent. Find two programs c₃ and c₄ such that neither approximates the other.

Find a program cmin that approximates every other program.

Finally, find a non-trivial property which is preserved by program approximation (when going from left to right).