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

Review: Programs' Denotations

Inductively Defined Denotational Semantics

Today, we turn to consider a different approach of defining denotational semantics. The following Coq commands define ceval as an inductive predicate.

What does this definition mean?

• First, it defines a ternary relation. We can see this from ceval's type. That is: com -> state -> state -> Prop. As we know, ceval c st st' means executing c from state st may end in st'.
• Second, in only 7 situations, command-state-state triples can appear in this ternary relation. These 7 situations are tagged by E_Skip, E_Ass, E_Seq, etc.
• Using E_Seq as an example, it says, if (c₁, st, st') is in this ternary relation and (c₂, st', st'') is in this ternary relation, then (c₁;; c₂, st', st'') is also in this relation. This is rule stating who can appear in ceval.
• Overall, this definition says every triple in ceval must have a reason, one of these 7 kinds. If it is based an assumption that another triple is in ceval, that one must have a reason as well.

This is called an inductive definition (归纳定义). Sometimes, we also call it a rule-based definition. It is worth noticing that this definition is very first-order, in contrast to the higher-order fashion in two previous lectures. Computer scientists even prefer not to call it denotational semantics but big-step semantics. That is, ceval c st st' holds if we can take a big step (executing c) from st and get to st'. You can find more information about it in << Software Foundations >> volume 1. Although we will not use this inductively defined ceval later in this course, but inductive definitions are widely used in programming language theories.

Understanding Inductive Propositions

Stone game

Consider a simple game between two players.

• There are n stones initially in a pile.
• Players move in turn.
• In his/her move, a player may remove one, two or three stones from the pile.
• Who makes the pile empty wins the game.

We can ask: if n = 10, can the first player to move win the game? In the classical game theory, every game state is either a previous-player-win state or a next-player-win state. In this example, a game state can be described by an integer, the number of stones left in the pile. And the question is just to ask whether 10 is a next-player-win state. Now, let's formalize these concepts in Coq.

Reflexive Transitive Closure

The reflexive, transitive closure of a relation R is the smallest relation that contains R and is both reflexive and transitive. All three following definitions express this same meaning.

Are they really equivalent? We can prove that they actually shares some common properties.

Induction On Inductive Propositions

We will use the following proof as an example to show how to do induction over an inductively defined proposition. You may ask why we can do induction proof. Intuitively, the reason of why clos_refl_trans_1n R x y is a proof tree. Thus, we can do structural induction over proof trees.

In fact, the revert befor induction is not necessary.

Now, try to finish a similar proof by yourself.

In the end, we can prove equivalences.

The other three directions are left as exercise.

32-bit Evaluation Again

In this course, the expression evaluation of integer expressions is unbounded, unlike the situation of normal programming languages like C and Java. But still, we can define "whether evaluating an expression a" is within the range of signed 32-bit integers. We have defined this property in our previous lectures. We redefine it again as an inductive predicate in Coq.

In short, signed32_eval a st v says that evaluating a on state st is within the range of signed 32-bit integers (including all intermediate results) the final result is v. Obviously, the evaluation result must coincide with the expressions' denotations defined by aeval.

Similarly, we can defined 16-bit evaluation.

Of course, 16-bit evaluation defines only a subset of 32-bit evaluation. Second half of the proof is left as exercise.

Moreover, from the definition of signed32_eval, we know that if all intermediate results of evaluating a on st fails in the range of 32-bit, the same property is also true for any a's subexpression a'. We first define sub_aexp.

In the following proof, we use inversion to do case analysis over inductive proposition. Moreover, subst is used to do substitution. In other words, if there is an assumption of form x = v (where x is a Coq variable), then x will be removed from the proof goal at all and its every occurrence is replaced with v.

Loop-free Programs

Now, we prove that a loop free program always terminate.

Try to understand why we need to strengthen the induction hypothesis here.

In order to construct a program state st₂ here. We want to use the following definition and proof from our last lectures.

Now we are ready to prove loop_free_terminate.

You migh wonder why we choose not to define "loop_free" by a recursive function. For example:

It is no problem. And you can try to prove a similar theorem about termination.

If we compare loop_free and loop_free_fun, the latter one is less flexible to extend.

This definition says: if an if-condition is always true, then the loops in its else-branch should not be considered as real loops. Similarly, if an if-condition is always false, then the loops in its then-branch should not be considered as real loops. Also, if a while-loop's loop condition is always false, the loop body will never be executed — that is not a real loop either.