-
Notifications
You must be signed in to change notification settings - Fork 3
/
Smallstep.v
1652 lines (1340 loc) · 54.2 KB
/
Smallstep.v
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
(** * Smallstep: Small-step Operational Semantics *)
Require Export Imp.
(** The evaluators we have seen so far (e.g., the ones for
[aexp]s, [bexp]s, and commands) have been formulated in a
"big-step" style -- they specify how a given expression can be
evaluated to its final value (or a command plus a store to a final
store) "all in one big step."
This style is simple and natural for many purposes -- indeed,
Gilles Kahn, who popularized its use, called it _natural
semantics_. But there are some things it does not do well. In
particular, it does not give us a natural way of talking about
_concurrent_ programming languages, where the "semantics" of a
program -- i.e., the essence of how it behaves -- is not just
which input states get mapped to which output states, but also
includes the intermediate states that it passes through along the
way, since these states can also be observed by concurrently
executing code.
Another shortcoming of the big-step style is more technical, but
critical in some situations. To see the issue, suppose we wanted
to define a variant of Imp where variables could hold _either_
numbers _or_ lists of numbers (see the [HoareList] chapter for
details). In the syntax of this extended language, it will be
possible to write strange expressions like [2 + nil], and our
semantics for arithmetic expressions will then need to say
something about how such expressions behave. One
possibility (explored in the [HoareList] chapter) is to maintain
the convention that every arithmetic expressions evaluates to some
number by choosing some way of viewing a list as a number -- e.g.,
by specifying that a list should be interpreted as [0] when it
occurs in a context expecting a number. But this is really a bit
of a hack.
A much more natural approach is simply to say that the behavior of
an expression like [2+nil] is _undefined_ -- it doesn't evaluate
to any result at all. And we can easily do this: we just have to
formulate [aeval] and [beval] as [Inductive] propositions rather
than Fixpoints, so that we can make them partial functions instead
of total ones.
However, now we encounter a serious deficiency. In this language,
a command might _fail_ to map a given starting state to any ending
state for two quite different reasons: either because the
execution gets into an infinite loop or because, at some point,
the program tries to do an operation that makes no sense, such as
adding a number to a list, and none of the evaluation rules can be
applied.
These two outcomes -- nontermination vs. getting stuck in an
erroneous configuration -- are quite different. In particular, we
want to allow the first (permitting the possibility of infinite
loops is the price we pay for the convenience of programming with
general looping constructs like [while]) but prevent the
second (which is just wrong), for example by adding some form of
_typechecking_ to the language. Indeed, this will be a major
topic for the rest of the course. As a first step, we need a
different way of presenting the semantics that allows us to
distinguish nontermination from erroneous "stuck states."
So, for lots of reasons, we'd like to have a finer-grained way of
defining and reasoning about program behaviors. This is the topic
of the present chapter. We replace the "big-step" [eval] relation
with a "small-step" relation that specifies, for a given program,
how the "atomic steps" of computation are performed. *)
(* ########################################################### *)
(** * Relations *)
(** A _relation_ on a set [X] is a family of propositions
parameterized by two elements of [X] -- i.e., a proposition about
pairs of elements of [X]. *)
Definition relation (X: Type) := X->X->Prop.
(** Our main examples of such relations in this chapter will be
the single-step and multi-step reduction relations on terms, [==>]
and [==>*], but there are many other examples -- some that come to
mind are the "equals," "less than," "less than or equal to," and
"is the square of" relations on numbers, and the "prefix of"
relation on lists and strings. *)
(* ########################################################### *)
(** * A Toy Language *)
(** To save space in the discussion, let's go back to an
incredibly simple language containing just constants and
addition. (We use single letters -- [C] and [P] -- for the
constructor names, for brevity.) At the end of the chapter, we'll
see how to apply the same techniques to the full Imp language. *)
Inductive tm : Type :=
| C : nat -> tm (* Constant *)
| P : tm -> tm -> tm. (* Plus *)
Tactic Notation "tm_cases" tactic(first) ident(c) :=
first;
[ Case_aux c "C" | Case_aux c "P" ].
(** Here is a standard evaluator for this language, written in the
same (big-step) style as we've been using up to this point. *)
Fixpoint evalF (t : tm) : nat :=
match t with
| C n => n
| P a1 a2 => evalF a1 + evalF a2
end.
(** Now, here is the same evaluator, written in exactly the same
style, but formulated as an inductively defined relation. Again,
we use the notation [t || n] for "[t] evaluates to [n]." *)
(**
-------- (E_Const)
C n || n
t1 || n1
t2 || n2
---------------------- (E_Plus)
P t1 t2 || C (n1 + n2)
*)
Reserved Notation " t '||' n " (at level 50, left associativity).
Inductive eval : tm -> nat -> Prop :=
| E_Const : forall n,
C n || n
| E_Plus : forall t1 t2 n1 n2,
t1 || n1 ->
t2 || n2 ->
P t1 t2 || (n1 + n2)
where " t '||' n " := (eval t n).
Tactic Notation "eval_cases" tactic(first) ident(c) :=
first;
[ Case_aux c "E_Const" | Case_aux c "E_Plus" ].
Module SimpleArith1.
(** Now, here is a small-step version. *)
(**
------------------------------- (ST_PlusConstConst)
P (C n1) (C n2) ==> C (n1 + n2)
t1 ==> t1'
-------------------- (ST_Plus1)
P t1 t2 ==> P t1' t2
t2 ==> t2'
--------------------------- (ST_Plus2)
P (C n1) t2 ==> P (C n1) t2'
*)
Reserved Notation " t '==>' t' " (at level 40).
Inductive step : tm -> tm -> Prop :=
| ST_PlusConstConst : forall n1 n2,
P (C n1) (C n2) ==> C (n1 + n2)
| ST_Plus1 : forall t1 t1' t2,
t1 ==> t1' ->
P t1 t2 ==> P t1' t2
| ST_Plus2 : forall n1 t2 t2',
t2 ==> t2' ->
P (C n1) t2 ==> P (C n1) t2'
where " t '==>' t' " := (step t t').
Tactic Notation "step_cases" tactic(first) ident(c) :=
first;
[ Case_aux c "ST_PlusConstConst"
| Case_aux c "ST_Plus1" | Case_aux c "ST_Plus2" ].
(** Things to notice:
- We are defining just a single reduction step, in which
one [P] node is replaced by its value.
- Each step finds the _leftmost_ [P] node that is ready to
go (both of its operands are constants) and rewrites it in
place. The first rule tells how to rewrite this [P] node
itself; the other two rules tell how to find it.
- A term that is just a constant cannot take a step. *)
(** Let's pause and check a couple of examples of reasoning with
the [step] relation... *)
(** If [t1] can take a step to [t1'], then [P t1 t2] steps
to [P t1' t2]: *)
Example test_step_1 :
P
(P (C 0) (C 3))
(P (C 2) (C 4))
==>
P
(C (0 + 3))
(P (C 2) (C 4)).
Proof.
apply ST_Plus1. apply ST_PlusConstConst. Qed.
(** **** Exercise: 1 star (test_step_2) *)
(** Right-hand sides of sums can take a step only when the
left-hand side is finished: if [t2] can take a step to [t2'],
then [P (C n) t2] steps to [P (C n)
t2']: *)
Example test_step_2 :
P
(C 0)
(P
(C 2)
(P (C 0) (C 3)))
==>
P
(C 0)
(P
(C 2)
(C (0 + 3))).
Proof.
(* FILL IN HERE *) Admitted.
(** [] *)
(** One simple property of the [==>] relation is that, like the
evaluation relation for our language of Imp programs, it is
_deterministic_.
_Theorem_: For each [t], there is at most one [t'] such that [t]
steps to [t'] ([t ==> t'] is provable). Formally, this is the
same as saying that [==>] is deterministic. *)
(** _Proof sketch_: We show that if [x] steps to both [y1] and [y2]
then [y1] and [y2] are equal, by induction on a derivation of
[step x y1]. There are several cases to consider, depending on
the last rule used in this derivation and in the given derivation
of [step x y2].
- If both are [ST_PlusConstConst], the result is immediate.
- The cases when both derivations end with [ST_Plus1] or
[ST_Plus2] follow by the induction hypothesis.
- It cannot happen that one is [ST_PlusConstConst] and the other
is [ST_Plus1] or [ST_Plus2], since this would imply that [x] has
the form [P t1 t2] where both [t1] and [t2] are
constants (by [ST_PlusConstConst]) _and_ one of [t1] or [t2] has
the form [P ...].
- Similarly, it cannot happen that one is [ST_Plus1] and the other
is [ST_Plus2], since this would imply that [x] has the form
[P t1 t2] where [t1] has both the form [P t1 t2] and
the form [C n]. [] *)
Definition deterministic {X: Type} (R: relation X) :=
forall x y1 y2 : X, R x y1 -> R x y2 -> y1 = y2.
Theorem step_deterministic:
deterministic step.
Proof.
unfold deterministic. intros x y1 y2 Hy1 Hy2.
generalize dependent y2.
step_cases (induction Hy1) Case; intros y2 Hy2.
Case "ST_PlusConstConst". step_cases (inversion Hy2) SCase.
SCase "ST_PlusConstConst". reflexivity.
SCase "ST_Plus1". inversion H2.
SCase "ST_Plus2". inversion H2.
Case "ST_Plus1". step_cases (inversion Hy2) SCase.
SCase "ST_PlusConstConst". rewrite <- H0 in Hy1. inversion Hy1.
SCase "ST_Plus1".
rewrite <- (IHHy1 t1'0).
reflexivity. assumption.
SCase "ST_Plus2". rewrite <- H in Hy1. inversion Hy1.
Case "ST_Plus2". step_cases (inversion Hy2) SCase.
SCase "ST_PlusConstConst". rewrite <- H1 in Hy1. inversion Hy1.
SCase "ST_Plus1". inversion H2.
SCase "ST_Plus2".
rewrite <- (IHHy1 t2'0).
reflexivity. assumption. Qed.
End SimpleArith1.
(* ########################################################### *)
(** ** Values *)
(** Let's take a moment to slightly generalize the way we state the
definition of single-step reduction. *)
(** It is useful to think of the [==>] relation as defining an
_abstract machine_:
- At any moment, the _state_ of the machine is a term.
- A _step_ of the machine is an atomic unit of computation --
here, a single "add" operation.
- The _halting states_ of the machine are ones where there is no
more computation to be done.
We can then execute a term [t] as follows:
- Take [t] as the starting state of the machine.
- Repeatedly use the [==>] relation to find a sequence of
machine states, starting with [t], where each state steps to
the next.
- When no more reduction is possible, "read out" the final state
of the machine as the result of execution. *)
(** Intuitively, it is clear that the final states of the
machine are always terms of the form [C n] for some [n].
We call such terms _values_. *)
Inductive value : tm -> Prop :=
v_const : forall n, value (C n).
(** Having introduced the idea of values, we can use it in the
definition of the [==>] relation to write [ST_Plus2] rule in a
slightly more elegant way: *)
(**
------------------------------- (ST_PlusConstConst)
P (C n1) (C n2) ==> C (n1 + n2)
t1 ==> t1'
-------------------- (ST_Plus1)
P t1 t2 ==> P t1' t2
value v1
t2 ==> t2'
-------------------- (ST_Plus2)
P v1 t2 ==> P v1 t2'
*)
(** Again, the variable names here carry important information:
by convention, [v1] ranges only over values, while [t1] and [t2]
range over arbitrary terms. (Given this convention, the explicit
[value] hypothesis is arguably redundant. We'll keep it for now,
to maintain a close correspondence between the informal and Coq
versions of the rules, but later on we'll drop it in informal
rules, for the sake of brevity.) *)
Reserved Notation " t '==>' t' " (at level 40).
Inductive step : tm -> tm -> Prop :=
| ST_PlusConstConst : forall n1 n2,
P (C n1) (C n2)
==> C (n1 + n2)
| ST_Plus1 : forall t1 t1' t2,
t1 ==> t1' ->
P t1 t2 ==> P t1' t2
| ST_Plus2 : forall v1 t2 t2',
value v1 -> (* <----- n.b. *)
t2 ==> t2' ->
P v1 t2 ==> P v1 t2'
where " t '==>' t' " := (step t t').
Tactic Notation "step_cases" tactic(first) ident(c) :=
first;
[ Case_aux c "ST_PlusConstConst"
| Case_aux c "ST_Plus1" | Case_aux c "ST_Plus2" ].
(** **** Exercise: 3 stars (redo_determinism) *)
(** As a sanity check on this change, let's re-verify determinism
Proof sketch: We must show that if [x] steps to both [y1] and [y2]
then [y1] and [y2] are equal. Consider the final rules used in
the derivations of [step x y1] and [step x y2].
- If both are [ST_PlusConstConst], the result is immediate.
- It cannot happen that one is [ST_PlusConstConst] and the other
is [ST_Plus1] or [ST_Plus2], since this would imply that [x] has
the form [P t1 t2] where both [t1] and [t2] are
constants (by [ST_PlusConstConst]) AND one of [t1] or [t2] has
the form [P ...].
- Similarly, it cannot happen that one is [ST_Plus1] and the other
is [ST_Plus2], since this would imply that [x] has the form
[P t1 t2] where [t1] both has the form [P t1 t2] and
is a value (hence has the form [C n]).
- The cases when both derivations end with [ST_Plus1] or
[ST_Plus2] follow by the induction hypothesis. [] *)
(** Most of this proof is the same as the one above. But to get
maximum benefit from the exercise you should try to write it from
scratch and just use the earlier one if you get stuck. *)
Theorem step_deterministic :
deterministic step.
Proof.
(* FILL IN HERE *) Admitted.
(** [] *)
(* ########################################################### *)
(** ** Strong Progress and Normal Forms *)
(** The definition of single-step reduction for our toy language is
fairly simple, but for a larger language it would be pretty easy
to forget one of the rules and create a situation where some term
cannot take a step even though it has not been completely reduced
to a value. The following theorem shows that we did not, in fact,
make such a mistake here. *)
(** _Theorem_ (_Strong Progress_): If [t] is a term, then either [t]
is a value, or there exists a term [t'] such that [t ==> t']. *)
(** _Proof_: By induction on [t].
- Suppose [t = C n]. Then [t] is a [value].
- Suppose [t = P t1 t2], where (by the IH) [t1] is either a
value or can step to some [t1'], and where [t2] is either a
value or can step to some [t2']. We must show [P t1 t2] is
either a value or steps to some [t'].
- If [t1] and [t2] are both values, then [t] can take a step, by
[ST_PlusConstConst].
- If [t1] is a value and [t2] can take a step, then so can [t],
by [ST_Plus2].
- If [t1] can take a step, then so can [t], by [ST_Plus1]. [] *)
Theorem strong_progress : forall t,
value t \/ (exists t', t ==> t').
Proof.
tm_cases (induction t) Case.
Case "C". left. apply v_const.
Case "P". right. inversion IHt1.
SCase "l". inversion IHt2.
SSCase "l". inversion H. inversion H0.
exists (C (n + n0)).
apply ST_PlusConstConst.
SSCase "r". inversion H0 as [t' H1].
exists (P t1 t').
apply ST_Plus2. apply H. apply H1.
SCase "r". inversion H as [t' H0].
exists (P t' t2).
apply ST_Plus1. apply H0. Qed.
(** This important property is called _strong progress_, because
every term either is a value or can "make progress" by stepping to
some other term. (The qualifier "strong" distinguishes it from a
more refined version that we'll see in later chapters, called
simply "progress.") *)
(** The idea of "making progress" can be extended to tell us something
interesting about [value]s: in this language [value]s are exactly
the terms that _cannot_ make progress in this sense.
To state this observation formally, let's begin by giving a name
to terms that cannot make progress. We'll call them _normal
forms_. *)
Definition normal_form {X:Type} (R:relation X) (t:X) : Prop :=
~ exists t', R t t'.
(** This definition actually specifies what it is to be a normal form
for an _arbitrary_ relation [R] over an arbitrary set [X], not
just for the particular single-step reduction relation over terms
that we are interested in at the moment. We'll re-use the same
terminology for talking about other relations later in the
course. *)
(** We can use this terminology to generalize the observation we made
in the strong progress theorem: in this language, normal forms and
values are actually the same thing. *)
Lemma value_is_nf : forall v,
value v -> normal_form step v.
Proof.
unfold normal_form. intros v H. inversion H.
intros contra. inversion contra. inversion H1.
Qed.
Lemma nf_is_value : forall t,
normal_form step t -> value t.
Proof. (* a corollary of [strong_progress]... *)
unfold normal_form. intros t H.
assert (G : value t \/ exists t', t ==> t').
SCase "Proof of assertion". apply strong_progress.
inversion G.
SCase "l". apply H0.
SCase "r". apply ex_falso_quodlibet. apply H. assumption. Qed.
Corollary nf_same_as_value : forall t,
normal_form step t <-> value t.
Proof.
split. apply nf_is_value. apply value_is_nf. Qed.
(** Why is this interesting?
Because [value] is a syntactic concept -- it is defined by looking
at the form of a term -- while [normal_form] is a semantic one --
it is defined by looking at how the term steps. It is not obvious
that these concepts should coincide!
Indeed, we could easily have written the definitions so that they
would not coincide... *)
(* ##################################################### *)
(** We might, for example, mistakenly define [value] so that it
includes some terms that are not finished reducing. *)
Module Temp1.
(* Open an inner module so we can redefine value and step. *)
Inductive value : tm -> Prop :=
| v_const : forall n, value (C n)
| v_funny : forall t1 n2, (* <---- *)
value (P t1 (C n2)).
Reserved Notation " t '==>' t' " (at level 40).
Inductive step : tm -> tm -> Prop :=
| ST_PlusConstConst : forall n1 n2,
P (C n1) (C n2) ==> C (n1 + n2)
| ST_Plus1 : forall t1 t1' t2,
t1 ==> t1' ->
P t1 t2 ==> P t1' t2
| ST_Plus2 : forall v1 t2 t2',
value v1 ->
t2 ==> t2' ->
P v1 t2 ==> P v1 t2'
where " t '==>' t' " := (step t t').
(** *)
(** **** Exercise: 3 stars, advanced (value_not_same_as_normal_form) *)
Lemma value_not_same_as_normal_form :
exists v, value v /\ ~ normal_form step v.
Proof.
(* FILL IN HERE *) Admitted.
(** [] *)
End Temp1.
(* ##################################################### *)
(** Alternatively, we might mistakenly define [step] so that it
permits something designated as a value to reduce further. *)
Module Temp2.
Inductive value : tm -> Prop :=
| v_const : forall n, value (C n).
Reserved Notation " t '==>' t' " (at level 40).
Inductive step : tm -> tm -> Prop :=
| ST_Funny : forall n, (* <---- *)
C n ==> P (C n) (C 0)
| ST_PlusConstConst : forall n1 n2,
P (C n1) (C n2) ==> C (n1 + n2)
| ST_Plus1 : forall t1 t1' t2,
t1 ==> t1' ->
P t1 t2 ==> P t1' t2
| ST_Plus2 : forall v1 t2 t2',
value v1 ->
t2 ==> t2' ->
P v1 t2 ==> P v1 t2'
where " t '==>' t' " := (step t t').
(** *)
(** **** Exercise: 2 stars, advanced (value_not_same_as_normal_form) *)
Lemma value_not_same_as_normal_form :
exists v, value v /\ ~ normal_form step v.
Proof.
(* FILL IN HERE *) Admitted.
(** [] *)
End Temp2.
(* ########################################################### *)
(** Finally, we might define [value] and [step] so that there is some
term that is not a value but that cannot take a step in the [step]
relation. Such terms are said to be _stuck_. In this case this is
caused by a mistake in the semantics, but we will also see
situations where, even in a correct language definition, it makes
sense to allow some terms to be stuck. *)
Module Temp3.
Inductive value : tm -> Prop :=
| v_const : forall n, value (C n).
Reserved Notation " t '==>' t' " (at level 40).
Inductive step : tm -> tm -> Prop :=
| ST_PlusConstConst : forall n1 n2,
P (C n1) (C n2) ==> C (n1 + n2)
| ST_Plus1 : forall t1 t1' t2,
t1 ==> t1' ->
P t1 t2 ==> P t1' t2
where " t '==>' t' " := (step t t').
(** (Note that [ST_Plus2] is missing.) *)
(** *)
(** **** Exercise: 3 stars, advanced (value_not_same_as_normal_form') *)
Lemma value_not_same_as_normal_form :
exists t, ~ value t /\ normal_form step t.
Proof.
(* FILL IN HERE *) Admitted.
(** [] *)
End Temp3.
(* ########################################################### *)
(** *** Additional Exercises *)
Module Temp4.
(** Here is another very simple language whose terms, instead of being
just plus and numbers, are just the booleans true and false and a
conditional expression... *)
Inductive tm : Type :=
| ttrue : tm
| tfalse : tm
| tif : tm -> tm -> tm -> tm.
Inductive value : tm -> Prop :=
| v_true : value ttrue
| v_false : value tfalse.
Reserved Notation " t '==>' t' " (at level 40).
Inductive step : tm -> tm -> Prop :=
| ST_IfTrue : forall t1 t2,
tif ttrue t1 t2 ==> t1
| ST_IfFalse : forall t1 t2,
tif tfalse t1 t2 ==> t2
| ST_If : forall t1 t1' t2 t3,
t1 ==> t1' ->
tif t1 t2 t3 ==> tif t1' t2 t3
where " t '==>' t' " := (step t t').
(** **** Exercise: 1 star (smallstep_bools) *)
(** Which of the following propositions are provable? (This is just a
thought exercise, but for an extra challenge feel free to prove
your answers in Coq.) *)
Definition bool_step_prop1 :=
tfalse ==> tfalse.
(* FILL IN HERE *)
Definition bool_step_prop2 :=
tif
ttrue
(tif ttrue ttrue ttrue)
(tif tfalse tfalse tfalse)
==>
ttrue.
(* FILL IN HERE *)
Definition bool_step_prop3 :=
tif
(tif ttrue ttrue ttrue)
(tif ttrue ttrue ttrue)
tfalse
==>
tif
ttrue
(tif ttrue ttrue ttrue)
tfalse.
(* FILL IN HERE *)
(** [] *)
(** **** Exercise: 3 stars, optional (progress_bool) *)
(** Just as we proved a progress theorem for plus expressions, we can
do so for boolean expressions, as well. *)
Theorem strong_progress : forall t,
value t \/ (exists t', t ==> t').
Proof.
(* FILL IN HERE *) Admitted.
(** [] *)
(** **** Exercise: 2 stars, optional (step_deterministic) *)
Theorem step_deterministic :
deterministic step.
Proof.
(* FILL IN HERE *) Admitted.
(** [] *)
Module Temp5.
(** **** Exercise: 2 stars (smallstep_bool_shortcut) *)
(** Suppose we want to add a "short circuit" to the step relation for
boolean expressions, so that it can recognize when the [then] and
[else] branches of a conditional are the same value (either
[ttrue] or [tfalse]) and reduce the whole conditional to this
value in a single step, even if the guard has not yet been reduced
to a value. For example, we would like this proposition to be
provable:
tif
(tif ttrue ttrue ttrue)
tfalse
tfalse
==>
tfalse.
*)
(** Write an extra clause for the step relation that achieves this
effect and prove [bool_step_prop4]. *)
Reserved Notation " t '==>' t' " (at level 40).
Inductive step : tm -> tm -> Prop :=
| ST_IfTrue : forall t1 t2,
tif ttrue t1 t2 ==> t1
| ST_IfFalse : forall t1 t2,
tif tfalse t1 t2 ==> t2
| ST_If : forall t1 t1' t2 t3,
t1 ==> t1' ->
tif t1 t2 t3 ==> tif t1' t2 t3
(* FILL IN HERE *)
where " t '==>' t' " := (step t t').
(** [] *)
Definition bool_step_prop4 :=
tif
(tif ttrue ttrue ttrue)
tfalse
tfalse
==>
tfalse.
Example bool_step_prop4_holds :
bool_step_prop4.
Proof.
(* FILL IN HERE *) Admitted.
(** [] *)
(** **** Exercise: 3 stars, optional (properties_of_altered_step) *)
(** It can be shown that the determinism and strong progress theorems
for the step relation in the lecture notes also hold for the
definition of step given above. After we add the clause
[ST_ShortCircuit]...
- Is the [step] relation still deterministic? Write yes or no and
briefly (1 sentence) explain your answer.
Optional: prove your answer correct in Coq.
*)
(* FILL IN HERE *)
(**
- Does a strong progress theorem hold? Write yes or no and
briefly (1 sentence) explain your answer.
Optional: prove your answer correct in Coq.
*)
(* FILL IN HERE *)
(**
- In general, is there any way we could cause strong progress to
fail if we took away one or more constructors from the original
step relation? Write yes or no and briefly (1 sentence) explain
your answer.
(* FILL IN HERE *)
*)
(** [] *)
End Temp5.
End Temp4.
(* ########################################################### *)
(** * Multi-Step Reduction *)
(** Until now, we've been working with the _single-step reduction_
relation [==>], which formalizes the individual steps of an
_abstract machine_ for executing programs.
We can also use this machine to reduce programs to completion --
to find out what final result they yield. This can be formalized
as follows:
- First, we define a _multi-step reduction relation_ [==>*], which
relates terms [t] and [t'] if [t] can reach [t'] by any number
of single reduction steps (including zero steps!).
- Then we define a "result" of a term [t] as a normal form that
[t] can reach by multi-step reduction. *)
(* ########################################################### *)
(** Since we'll want to reuse the idea of multi-step reduction many
times in this and future chapters, let's take a little extra
trouble here and define it generically.
Given a relation [R], we define a relation [multi R], called the
_multi-step closure of [R]_ as follows: *)
Inductive multi {X:Type} (R: relation X) : relation X :=
| multi_refl : forall (x : X), multi R x x
| multi_step : forall (x y z : X),
R x y ->
multi R y z ->
multi R x z.
(** The effect of this definition is that [multi R] relates two
elements [x] and [y] if either
- [x = y], or else
- there is some sequence [z1], [z2], ..., [zn]
such that
R x z1
R z1 z2
...
R zn y.
Thus, if [R] describes a single-step of computation, [z1],
... [zn] is the sequence of intermediate steps of computation
between [x] and [y].
*)
Tactic Notation "multi_cases" tactic(first) ident(c) :=
first;
[ Case_aux c "multi_refl" | Case_aux c "multi_step" ].
(** We write [==>*] for the [multi step] relation -- i.e., the
relation that relates two terms [t] and [t'] if we can get from
[t] to [t'] using the [step] relation zero or more times. *)
Definition multistep := multi step.
Notation " t '==>*' t' " := (multistep t t') (at level 40).
(** The relation [multi R] has several crucial properties.
First, it is obviously _reflexive_ (that is, [forall x, multi R x
x]). In the case of the [==>*] (i.e. [multi step]) relation, the
intuition is that a term can execute to itself by taking zero
steps of execution.
Second, it contains [R] -- that is, single-step executions are a
particular case of multi-step executions. (It is this fact that
justifies the word "closure" in the term "multi-step closure of
[R].") *)
Theorem multi_R : forall (X:Type) (R:relation X) (x y : X),
R x y -> (multi R) x y.
Proof.
intros X R x y H.
apply multi_step with y. apply H. apply multi_refl. Qed.
(** Third, [multi R] is _transitive_. *)
Theorem multi_trans :
forall (X:Type) (R: relation X) (x y z : X),
multi R x y ->
multi R y z ->
multi R x z.
Proof.
intros X R x y z G H.
multi_cases (induction G) Case.
Case "multi_refl". assumption.
Case "multi_step".
apply multi_step with y. assumption.
apply IHG. assumption. Qed.
(** That is, if [t1==>*t2] and [t2==>*t3], then [t1==>*t3]. *)
(* ########################################################### *)
(** ** Examples *)
Lemma test_multistep_1:
P
(P (C 0) (C 3))
(P (C 2) (C 4))
==>*
C ((0 + 3) + (2 + 4)).
Proof.
apply multi_step with
(P
(C (0 + 3))
(P (C 2) (C 4))).
apply ST_Plus1. apply ST_PlusConstConst.
apply multi_step with
(P
(C (0 + 3))
(C (2 + 4))).
apply ST_Plus2. apply v_const.
apply ST_PlusConstConst.
apply multi_R.
apply ST_PlusConstConst. Qed.
(** Here's an alternate proof that uses [eapply] to avoid explicitly
constructing all the intermediate terms. *)
Lemma test_multistep_1':
P
(P (C 0) (C 3))
(P (C 2) (C 4))
==>*
C ((0 + 3) + (2 + 4)).
Proof.
eapply multi_step. apply ST_Plus1. apply ST_PlusConstConst.
eapply multi_step. apply ST_Plus2. apply v_const.
apply ST_PlusConstConst.
eapply multi_step. apply ST_PlusConstConst.
apply multi_refl. Qed.
(** **** Exercise: 1 star, optional (test_multistep_2) *)
Lemma test_multistep_2:
C 3 ==>* C 3.
Proof.
(* FILL IN HERE *) Admitted.
(** [] *)
(** **** Exercise: 1 star, optional (test_multistep_3) *)
Lemma test_multistep_3:
P (C 0) (C 3)
==>*
P (C 0) (C 3).
Proof.
(* FILL IN HERE *) Admitted.
(** [] *)
(** **** Exercise: 2 stars (test_multistep_4) *)
Lemma test_multistep_4:
P
(C 0)
(P
(C 2)
(P (C 0) (C 3)))
==>*
P
(C 0)
(C (2 + (0 + 3))).
Proof.
(* FILL IN HERE *) Admitted.
(** [] *)
(* ########################################################### *)
(** ** Normal Forms Again *)
(** If [t] reduces to [t'] in zero or more steps and [t'] is a
normal form, we say that "[t'] is a normal form of [t]." *)
Definition step_normal_form := normal_form step.
Definition normal_form_of (t t' : tm) :=
(t ==>* t' /\ step_normal_form t').
(** We have already seen that, for our language, single-step reduction is
deterministic -- i.e., a given term can take a single step in
at most one way. It follows from this that, if [t] can reach
a normal form, then this normal form is unique. In other words, we
can actually pronounce [normal_form t t'] as "[t'] is _the_
normal form of [t]." *)
(** **** Exercise: 3 stars, optional (normal_forms_unique) *)
Theorem normal_forms_unique:
deterministic normal_form_of.
Proof.
unfold deterministic. unfold normal_form_of. intros x y1 y2 P1 P2.
inversion P1 as [P11 P12]; clear P1. inversion P2 as [P21 P22]; clear P2.
generalize dependent y2.
(* We recommend using this initial setup as-is! *)
(* FILL IN HERE *) Admitted.
(** [] *)
(** Indeed, something stronger is true for this language (though not
for all languages): the reduction of _any_ term [t] will
eventually reach a normal form -- i.e., [normal_form_of] is a
_total_ function. Formally, we say the [step] relation is
_normalizing_. *)
Definition normalizing {X:Type} (R:relation X) :=
forall t, exists t',
(multi R) t t' /\ normal_form R t'.
(** To prove that [step] is normalizing, we need a couple of lemmas.
First, we observe that, if [t] reduces to [t'] in many steps, then
the same sequence of reduction steps within [t] is also possible
when [t] appears as the left-hand child of a [P] node, and
similarly when [t] appears as the right-hand child of a [P]
node whose left-hand child is a value. *)