comparison src/Universes.v @ 231:bc0f515a929f

New release
author Adam Chlipala <adamc@hcoop.net>
date Mon, 23 Nov 2009 12:41:14 -0500
parents 9dbcd6bad488
children f15f7c4eebfe
comparison
equal deleted inserted replaced
230:9dbcd6bad488 231:bc0f515a929f
86 Type $ Top.3 ^ 86 Type $ Top.3 ^
87 : Type $ (Top.3)+1 ^ 87 : Type $ (Top.3)+1 ^
88 88
89 ]] 89 ]]
90 90
91 Occurrences of [Type] are annotated with some additional information, inside comments. These annotations have to do with the secret behind [Type]: it Sreally stands for an infinite hierarchy of types. The type of [Set] is [Type(0)], the type of [Type(0)] is [Type(1)], the type of [Type(1)] is [Type(2)], and so on. This is how we avoid the "[Type : Type]" paradox. As a convenience, the universe hierarchy drives Coq's one variety of subtyping. Any term whose type is [Type] at level [i] is automatically also described by [Type] at level [j] when [j > i]. 91 Occurrences of [Type] are annotated with some additional information, inside comments. These annotations have to do with the secret behind [Type]: it really stands for an infinite hierarchy of types. The type of [Set] is [Type(0)], the type of [Type(0)] is [Type(1)], the type of [Type(1)] is [Type(2)], and so on. This is how we avoid the "[Type : Type]" paradox. As a convenience, the universe hierarchy drives Coq's one variety of subtyping. Any term whose type is [Type] at level [i] is automatically also described by [Type] at level [j] when [j > i].
92 92
93 In the outputs of our first [Check] query, we see that the type level of [Set]'s type is [(0)+1]. Here [0] stands for the level of [Set], and we increment it to arrive at the level that %\textit{%#<i>#classifies#</i>#%}% [Set]. 93 In the outputs of our first [Check] query, we see that the type level of [Set]'s type is [(0)+1]. Here [0] stands for the level of [Set], and we increment it to arrive at the level that %\textit{%#<i>#classifies#</i>#%}% [Set].
94 94
95 In the second query's output, we see that the occurrence of [Type] that we check is assigned a fresh %\textit{%#<i>#universe variable#</i>#%}% [Top.3]. The output type increments [Top.3] to move up a level in the universe hierarchy. As we write code that uses definitions whose types mention universe variables, unification may refine the values of those variables. Luckily, the user rarely has to worry about the details. 95 In the second query's output, we see that the occurrence of [Type] that we check is assigned a fresh %\textit{%#<i>#universe variable#</i>#%}% [Top.3]. The output type increments [Top.3] to move up a level in the universe hierarchy. As we write code that uses definitions whose types mention universe variables, unification may refine the values of those variables. Luckily, the user rarely has to worry about the details.
96 96
268 268
269 %\medskip% 269 %\medskip%
270 270
271 Something interesting is revealed in the annotated definition of [prod]. A type [prod A B] lives at a universe that is the maximum of the universes of [A] and [B]. From our earlier experiments, we might expect that [prod]'s universe would in fact need to be %\textit{%#<i>#one higher#</i>#%}% than the maximum. The critical difference is that, in the definition of [prod], [A] and [B] are defined as %\textit{%#<i>#parameters#</i>#%}%; that is, they appear named to the left of the main colon, rather than appearing (possibly unnamed) to the right. 271 Something interesting is revealed in the annotated definition of [prod]. A type [prod A B] lives at a universe that is the maximum of the universes of [A] and [B]. From our earlier experiments, we might expect that [prod]'s universe would in fact need to be %\textit{%#<i>#one higher#</i>#%}% than the maximum. The critical difference is that, in the definition of [prod], [A] and [B] are defined as %\textit{%#<i>#parameters#</i>#%}%; that is, they appear named to the left of the main colon, rather than appearing (possibly unnamed) to the right.
272 272
273 Parameters are not as flexible as normal inductive type arguments. The range types of all of the constructors of a parameterized type must share the same indices. Nonetheless, when it is possible to define a polymorphic type in this way, we gain the ability to use the new type family in more ways, without triggering universe inconsistencies. For instance, nested pairs of types are perfectly legal. *) 273 Parameters are not as flexible as normal inductive type arguments. The range types of all of the constructors of a parameterized type must share the same parameters. Nonetheless, when it is possible to define a polymorphic type in this way, we gain the ability to use the new type family in more ways, without triggering universe inconsistencies. For instance, nested pairs of types are perfectly legal. *)
274 274
275 Check (nat, (Type, Set)). 275 Check (nat, (Type, Set)).
276 (** %\vspace{-.15in}% [[ 276 (** %\vspace{-.15in}% [[
277 (nat, (Type $ Top.44 ^ , Set)) 277 (nat, (Type $ Top.44 ^ , Set))
278 : Set * (Type $ Top.45 ^ * Type $ Top.46 ^ ) 278 : Set * (Type $ Top.45 ^ * Type $ Top.46 ^ )
457 457
458 We will motivate the idea by touring through some standard axioms, as enumerated in Coq's online FAQ. I will add additional commentary as appropriate. *) 458 We will motivate the idea by touring through some standard axioms, as enumerated in Coq's online FAQ. I will add additional commentary as appropriate. *)
459 459
460 (** ** The Basics *) 460 (** ** The Basics *)
461 461
462 (* One simple example of a useful axiom is the law of the excluded middle. *) 462 (** One simple example of a useful axiom is the law of the excluded middle. *)
463 463
464 Require Import Classical_Prop. 464 Require Import Classical_Prop.
465 Print classic. 465 Print classic.
466 (** %\vspace{-.15in}% [[ 466 (** %\vspace{-.15in}% [[
467 *** [ classic : forall P : Prop, P \/ ~ P ] 467 *** [ classic : forall P : Prop, P \/ ~ P ]
496 496
497 (** On the subject of the law of the excluded middle itself, this axiom is usually quite harmless, and many practical Coq developments assume it. It has been proved metatheoretically to be consistent with CIC. Here, "proved metatheoretically" means that someone proved on paper that excluded middle holds in a %\textit{%#<i>#model#</i>#%}% of CIC in set theory. All of the other axioms that we will survey in this section hold in the same model, so they are all consistent together. 497 (** On the subject of the law of the excluded middle itself, this axiom is usually quite harmless, and many practical Coq developments assume it. It has been proved metatheoretically to be consistent with CIC. Here, "proved metatheoretically" means that someone proved on paper that excluded middle holds in a %\textit{%#<i>#model#</i>#%}% of CIC in set theory. All of the other axioms that we will survey in this section hold in the same model, so they are all consistent together.
498 498
499 Recall that Coq implements %\textit{%#<i>#constructive#</i>#%}% logic by default, where excluded middle is not provable. Proofs in constructive logic can be thought of as programs. A [forall] quantifier denotes a dependent function type, and a disjunction denotes a variant type. In such a setting, excluded middle could be interpreted as a decision procedure for arbitrary propositions, which computability theory tells us cannot exist. Thus, constructive logic with excluded middle can no longer be associated with our usual notion of programming. 499 Recall that Coq implements %\textit{%#<i>#constructive#</i>#%}% logic by default, where excluded middle is not provable. Proofs in constructive logic can be thought of as programs. A [forall] quantifier denotes a dependent function type, and a disjunction denotes a variant type. In such a setting, excluded middle could be interpreted as a decision procedure for arbitrary propositions, which computability theory tells us cannot exist. Thus, constructive logic with excluded middle can no longer be associated with our usual notion of programming.
500 500
501 Given all this, why is it all right to assert excluded middle as an axiom? I do not want to go into the technical details, but the intuitive justification is that the elimination restriction for [Prop] prevents us from treating proofs as programs. An excluded middle axiom that quantified over [Set] instead of [Prop] %\textit{%#<i>#would#</i>#%}% be problematic. If a development used that axiom, we would not be able to extract the code to OCaml (soundly) without implementing a genuine universal decision procedure. In contrast, values whose types belong to [Prop] are always erased by extraction, so we sidestep the axiom's algorithmic consequences. 501 Given all this, why is it all right to assert excluded middle as an axiom? The intuitive justification is that the elimination restriction for [Prop] prevents us from treating proofs as programs. An excluded middle axiom that quantified over [Set] instead of [Prop] %\textit{%#<i>#would#</i>#%}% be problematic. If a development used that axiom, we would not be able to extract the code to OCaml (soundly) without implementing a genuine universal decision procedure. In contrast, values whose types belong to [Prop] are always erased by extraction, so we sidestep the axiom's algorithmic consequences.
502 502
503 Because the proper use of axioms is so precarious, there are helpful commands for determining which axioms a theorem relies on. *) 503 Because the proper use of axioms is so precarious, there are helpful commands for determining which axioms a theorem relies on. *)
504 504
505 Theorem t1 : forall P : Prop, P -> ~ ~ P. 505 Theorem t1 : forall P : Prop, P -> ~ ~ P.
506 tauto. 506 tauto.
527 Axioms: 527 Axioms:
528 classic : forall P : Prop, P \/ ~ P 528 classic : forall P : Prop, P \/ ~ P
529 529
530 ]] 530 ]]
531 531
532 It is possible to avoid this dependence in some specific cases, where excluded middle %\textit{%#<i>#is#</i>#%}% provable, for decidable propositions. *) 532 It is possible to avoid this dependence in some specific cases, where excluded middle %\textit{%#<i>#is#</i>#%}% provable, for decidable families of propositions. *)
533 533
534 Theorem classic_nat_eq : forall n m : nat, n = m \/ n <> m. 534 Theorem classic_nat_eq : forall n m : nat, n = m \/ n <> m.
535 induction n; destruct m; intuition; generalize (IHn m); intuition. 535 induction n; destruct m; intuition; generalize (IHn m); intuition.
536 Qed. 536 Qed.
537 537
553 (** %\vspace{-.15in}% [[ 553 (** %\vspace{-.15in}% [[
554 *** [ proof_irrelevance : forall (P : Prop) (p1 p2 : P), p1 = p2 ] 554 *** [ proof_irrelevance : forall (P : Prop) (p1 p2 : P), p1 = p2 ]
555 555
556 ]] 556 ]]
557 557
558 This axiom asserts that any two proofs of the same proposition are equal. If we replaced [p1 = p2] by [p1 <-> p2], then the statement would be provable. However, without this axiom, equality is a stronger notion than logical equivalence. Recall this example function from Chapter 6. *) 558 This axiom asserts that any two proofs of the same proposition are equal. If we replaced [p1 = p2] by [p1 <-> p2], then the statement would be provable. However, equality is a stronger notion than logical equivalence. Recall this example function from Chapter 6. *)
559 559
560 (* begin hide *) 560 (* begin hide *)
561 Lemma zgtz : 0 > 0 -> False. 561 Lemma zgtz : 0 > 0 -> False.
562 crush. 562 crush.
563 Qed. 563 Qed.
613 match goal with 613 match goal with
614 | [ |- ?pf1 = ?pf2 ] => rewrite (UIP_refl pf1); rewrite (UIP_refl pf2); reflexivity 614 | [ |- ?pf1 = ?pf2 ] => rewrite (UIP_refl pf1); rewrite (UIP_refl pf2); reflexivity
615 end. 615 end.
616 Qed. 616 Qed.
617 617
618 (** These corollaries are special cases of proof irrelevance. Many developments only need proof irrelevance for equality, so there is no need to assert full irrelevance for them. 618 (** These corollaries are special cases of proof irrelevance. In developments that only need proof irrelevance for equality, there is no need to assert full irrelevance.
619 619
620 Another facet of proof irrelevance is that, like excluded middle, it is often provable for specific propositions. For instance, [UIP] is provable whenever the type [A] has a decidable equality operation. The module [Eqdep_dec] of the standard library contains a proof. A similar phenomenon applies to other notable cases, including less-than proofs. Thus, it is often possible to use proof irrelevance without asserting axioms. 620 Another facet of proof irrelevance is that, like excluded middle, it is often provable for specific propositions. For instance, [UIP] is provable whenever the type [A] has a decidable equality operation. The module [Eqdep_dec] of the standard library contains a proof. A similar phenomenon applies to other notable cases, including less-than proofs. Thus, it is often possible to use proof irrelevance without asserting axioms.
621 621
622 %\bigskip% 622 %\bigskip%
623 623
663 (** %\vspace{-.15in}% [[ 663 (** %\vspace{-.15in}% [[
664 Closed under the global context 664 Closed under the global context
665 665
666 ]] 666 ]]
667 667
668 This function transforms a decidable predicate [P] into a function that produces an element satisfying [P] from a proof that such an element exists. The functions [f] and [g], plus an associated injectivity property, are used to express the idea that the set [A] is countable. Under these conditions, a simple brute force algorithm gets the job done: we just enumerate all elements of [A], stopping when we find one satisfying [P]. The existence proof, specified in terms of %\textit{%#<i>#unique#</i>#%}% existence [exists!], guarantees termination. The definition of this operator in Coq uses some interesting techniques, as seen in the implementation of the [ConstructiveEpsilon] module. 668 This function transforms a decidable predicate [P] into a function that produces an element satisfying [P] from a proof that such an element exists. The functions [f] and [g], in conjunction with an associated injectivity property, are used to express the idea that the set [A] is countable. Under these conditions, a simple brute force algorithm gets the job done: we just enumerate all elements of [A], stopping when we find one satisfying [P]. The existence proof, specified in terms of %\textit{%#<i>#unique#</i>#%}% existence [exists!], guarantees termination. The definition of this operator in Coq uses some interesting techniques, as seen in the implementation of the [ConstructiveEpsilon] module.
669 669
670 Countable choice is provable in set theory without appealing to the general axiom of choice. To support the more general principle in Coq, we must also add an axiom. Here is a functional version of the axiom of unique choice. *) 670 Countable choice is provable in set theory without appealing to the general axiom of choice. To support the more general principle in Coq, we must also add an axiom. Here is a functional version of the axiom of unique choice. *)
671 671
672 Require Import ClassicalUniqueChoice. 672 Require Import ClassicalUniqueChoice.
673 Check dependent_unique_choice. 673 Check dependent_unique_choice.