Remark. Some material in this lecture is from << Software Foundation >> volume 1 and volume 2.

General Idea: Small Step

Till now, we have learnt how to define a programming language's denotational semantics. Most commonly, the denotation of a program is defined as a binary relation between program states. Such denotational semantics are also called big-step operational semantics — the denotation of a program tells the result of program execution (given the starting state), "all in one step". Small step semantics, on the other hand, talks more about intermediate states. It defines how a program will execute, step by step. If we use the following expression's evaluation process as example, denotational semantics says: while small step operational semantics says: In short, we will learn how to define a "small-step" relation that specifies, for a given program, how the "atomic steps" of computation are performed.

Small Step Semantics for Expression Evaluation

It can be useful to think of this step relation of expression evaluation as an abstract machine.

• At any moment, the state of the machine is an integer expression.
• A step of this machine is an atomic unit of computation — here, a single arithmetic operation or loading program variable's value.
• The halting states of the machine are ones where there is no more computation to be done.

Given an expression a, we can compute its value as follows:

• Take a as the starting state of the machine.
• Repeatedly use the step relation to find a sequence of machine states, starting with a, where each state steps to the next.
• When no more forward step is possible, "read out" the final state of the machine as the result of computation.

Intuitively, it is clear that the final states of the machine are always constant expressions Anum n for some n.

Of course, we could define it using a Coq function instead of an inductive predicate. Here is this alternative (but equivalent approach) approach.

Then we define our step relation.

This definition seems to be super long. Let's read it part by part. But please keep in mind that what we define here is only a single step evaluation relation. The first part of this definition talks about the value of a program variable: In short, it says: a program variable X's variable is X's variable and this evaluation process has only one step. The second part of this definition talks about how the sum of two subexpressions are computed. It says, the left side is computed first, then the right side. When both sides are computed, the sum of them can be computed in another step. In the theory of programming languages, such inductive definitions are also inference rules. For example, Usually, every inference rule has a horizontal line, what sits above it is assumptions and the conclusion is below the line. Combining all rules together, we are already able to describe the evaluation process of some nontrivial examples. For example, when X's value is 1 and Y's value is 2, X + (3 + Y) will be evaluated by the following steps: We can prove our examples in Coq.

We define bool expressions' evaluation similarly. If you forget details about bexp's inductive definition, just use Print bexp as a cheat sheet.

Remark: when evaluating a conjunction of two boolean expression, we use short circuit evaluation. That is, the right hand side will not be evaluated if the left hand side is false. For example, when X's value is 1, X ≤ 0 && 0 < X + 10 will be evaluated by the following steps:

Multi-step Relation

We can now use the single-step relations and their reflexive, transitive closure to formalize an entire execution.

Intuitively, if multi_astep st a₁ a₂ is true, then a₂ is an intermidiate result of evaluating a₁ on st. And multi_bstep st b₁ b₂ says that b₂ is an intermidiate result of evaluating b₁ on st. Here is several examples. Remark. In these examples and our later lecture notes, we will reason about different properties about reflexive transitive closures. Our RTClosure library provide tactic supports for these proofs. These tactics include:

• induction_1n and induction_n₁;
• transitivity_1n, transitivity_n₁, etransitivity_1n and etransitivity_n₁;
• unfold_with_1n and unfold_with_n₁.

Also, since reflexive transitive closures are reflexive and transitive, RTClosure libraries provide corresponding instances so that Coq's reflexivity, transitivity and etransitivity can be used. You can find more detailed information in the additional reading part.

The multi-step relations satisfy the congruence property. For example, the following theorem says: Why? Because for every single step from a₁ to a₁', we can construct a corresponding step from a₁ + a₂ to a₁' + a₂.

Remark: we could complete this proof using different induction principles like the style of trans, of trans_1n instead of trans_n₁.

It is critical that we require a₁ to be a constant.

Here we go. Without the assumption H: aexp_halt a₁, we cannot complete our proof here.

We can prove similar properties for AMinus, AMult, BEq, BLe, BNot and BAnd.

Small Step Semantics for Simple Imperative Programes

The semantics of commands is more interesting. For expression evaluation, the program states are stable. In other words, we only talked about how an expression will be reduced to another one on a fixed program state. But for program execution, the program states are modified. Thus, a ternary relation among the program state, the command to execute and the residue command after one step is not expressive enough to describe programs' behavior. A quaternary relation is needed. Specifically, we would like to define a predicate cstep such that says if the program to execute is c₁, the taking one step forward on state st₁ may end in state st₂ while the residue command is c₂. Traditionally, computer scientist will describe their theory in a slightly different form. They usually treat cstep as a binary relation between state-command pairs and use the following notation: We will follow this style in our course, i.e. we will write Technically, this is also more convenient for us to define its reflexive transitive closure later.

Definition of Program Steps

Here is our definition of small step semantics for program execution. In this definition, we use (com * state) in Coq to represent the set of command-program pairs. You can find more information about this Coq data type in the additional reading part.

In this definition, we use two small tricks:

• We use Skip as an "empty residue command".
  • An assignment command reduces to Skip (and an updated state).
  • The sequencing command waits until its left-hand subcommand has reduced to Skip, then throws it away so that reduction can continue with the right-hand subcommand.
• We reduce a While command by transforming it into a conditional followed by the same While.

For example, Here is another example,

Multi-step Relation

Similar to the small step semantics for expression evaluation, the multi-step relation for cstep also has its own congruence property. We prove two typical ones here.

Additional Reading: Pairs as Coq Data Type

In Coq, product types are defined as the follow polymorphic inductive type. This declaration can be read: "There is just one way to construct an A-B pair: by applying the constructor pair to two arguments of type A and B."

Here are simple functions for extracting the first and second components of a pair.

Note that the pair notation can also be used in pattern matching.

Let's try to prove a few simple facts about pairs. If we state things in a slightly peculiar way, we can complete proofs with just reflexivity (and its built-in simplification):

Here, we can see the effect of simpl.

But reflexivity is not enough if we state the lemma in a more natural way:

We have to expose the structure of p so that simpl can perform the pattern match in fst and snd. We can do this with destruct.

Exercise: 1 star, standard (snd_fst_is_swap)

These definitions about pairs are all built in Coq's standard library.

Additional Reading: Support For Reflexive Transitive Closure

We already know that three different definitions of reflexive transitive closures are equivalent. If we define a multi-step relation using clos_refl_trans but want to prove related properties via an equivalent transformation to clos_refl_trans_1n, we can use unfold_with_1n. Here is an example:

We provide similar support for clos_refl_trans_n₁.

If you just want to do clos_refl_trans_1n's induction principle, you can use induction_1n.

We know that multi_astep must be reflexive since it is defined by a reflexive transitive closure. We can use reflexivity here.

Here, if we directly use transitivity via intemidiate state a₁ + a₂, we have to prove in Coq that

• multi_astep st (a₀ + a₂) (a₁ + a₂)
• multi_astep st (a₁ + a₂) (a₁' + a₂)

Then, for the first target, we will use rt_step to complete the proof. It is inconvenient. Using a transitivity of rt_trans_1n's style is better. RTClosure library provides transitivity_1n.

If you do not want to manually provide an intermediate state, you can use etransitivity_1n.

RTClosure provides similar supports via induction_n₁, transitivity_n₁ and etransitivity_n₁.

In the end, we discuss a technique issue of doing manual induction in Coq. We will use multi_congr_CSeq as an example here.

This time, we will use unfold_with_n₁ and try to use the induction principle of clos_refl_trans_n₁ manually to complete the proof.

The problem here is, Coq's induction tactic on inductive predicates requires that predicate takes only Coq variables as its argument. Any other internal structures are not allowed, or else necessary information might be lost. In the case above, we do induction over: In this hypothesis, (c₁, st₁) and (c₁', st₁') are not simple Coq variables. Thus, Coq cannot find a common pattern between big proof trees and small proof trees, which causes problems in manual induction. Coq provides the remember tactic for necessary transitions.

These two commands say: use cst and cst' to represent those two pairs. And use two equalities H₀ and H₁ to record this replacement.

This branch corresponds to the case that is true because of reflexivity. The subst will find H₀: x = (c₁, st₁) and replace every occurrence of x with (c₁, st₁).

Now, H₁ says and pair is a constructor for product type. Since all constructors are injective, we can achieve c₁ = c₁' and st₁ = st₁'.

This branch corresponds to the case that is true because there exists another pair c₁'', st'', such that holds.

Of course, manually work-around of using remember, revert, subst and injection is inconvenient. RTClosure's induction_n₁ does that for you.