Mercurial > cpdt > repo
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. |