Warum hat Coq Prop?

Coq hat eine Art Prop of Proof irrelevante Aussagen, die während der Extraktion verworfen werden. Was ist der Grund dafür, wenn wir Coq nur für Proofs verwenden? Prop ist aussagekräftig, ~~daher~~ leitet Coq jedoch automatisch Universumsindizes ein, und wir können stattdessen überall Type (i) verwenden. Es scheint, dass Prop alles sehr kompliziert macht.

Ich habe gelesen, dass es in Luos Buch philosophische Gründe gibt, Set und Prop zu trennen, aber ich habe sie nicht in dem Buch gefunden. Was sind Sie?

coq dependent-type

— Konstantin Solomatov
quelle

"Wenn wir Coq nur für Beweise verwenden": Ich denke, Sie haben hier einen wichtigen Punkt identifiziert. Coq wird nicht nur für Proofs verwendet.

— Gilles 'SO- hör auf böse zu sein'

Antworten:

ist sehr nützlich für das Extrahieren von Programmen, da es uns ermöglicht, Teile von Code zu löschen, die unbrauchbar sind. Um zum Beispiel einen Sortieralgorithmus extrahieren wir die Aussage beweisen würden „für jede Liste gibt es eine Liste , so dass bestellt und ist eine permutatiom von “. Wenn wir dies in Coq aufschreiben und ohne extrahieren, erhalten wir: $\mathtt{Prop}$ $\ell$ $k$ $k$ $k$ $\ell$ $\mathtt{Prop}$

„für alle gibt es “ wird uns eine Karte , die Listen Listen nimmt, $\ell$ $k$ sort
"so dass geordnet ist" gibt eine Funktion, die durchläuft und prüft, ob es sortiert ist, und $k$ verify $k$
" ist eine Permutation von " ergibt eine Permutation, die für . Beachten Sie, dass dies nicht nur ein Mapping ist, sondern auch das inverse Mapping zusammen mit Programmen, die überprüfen, ob die beiden Maps wirklich invers sind. $k$ $\ell$ pi $\ell$ $k$ pi

Während das zusätzliche Zeug nicht völlig nutzlos ist, wollen wir es in vielen Anwendungen loswerden und einfach behalten sort. Dies kann erreicht werden, wenn wir mit angeben, " ist geordnet" und " ist eine Permutation von ", aber nicht "für alle gibt es ". $\mathtt{Prop}$ $k$ $k$ $\ell$ $\ell$ $k$

Im Allgemeinen besteht eine übliche Methode zum Extrahieren von Code darin, eine Anweisung der Form wobei eingegeben wird, ausgegeben wird und erklärt, was es bedeutet, dass eine korrekte Ausgabe ist. (In dem obigen Beispiel und sind die Arten von Listen und ist " bestellt wirdund ist eine Permutation von ") Wenn in ist dann Extraktion eine Karte gibt $\forall x : A \,.\, \exists y : B \,.\, \phi(x, y)$ $x$ $y$ $\phi(x,y)$ $y$ $A$ $B$ $\phi(\ell, k)$ $k$ $k$ $\ell$ $\phi$ $\mathtt{Prop}$ so, dass für alle . Wenn in ist dann bekommen wir auch eine Funktion , so dass ist der Beweisdass gilt, für alle $f : A \to B$ $\phi(x, f(x))$ $x \in A$ $\phi$ $\mathtt{Set}$ $g$ $g(x)$ $\phi(x, f(x))$ $x \in A$ . Oft ist der Beweis rechnerisch nutzlos und wir ziehen es vor, ihn loszuwerden, besonders wenn er tief in einer anderen Anweisung verschachtelt ist. gibt uns die Möglichkeit dazu. $\mathtt{Prop}$

Hinzugefügt am 29.07.2015: Es gibt eine Frage, ob wir ganz vermeiden könnten, indem wir automatisch "nutzlos extrahierten Code" wegoptimieren . Bis zu einem gewissen Grad können wir das tun, zum Beispiel ist der gesamte Code, der aus dem negativen Fragment der Logik extrahiert wurde (Material, das aus dem leeren Typ, dem Einheitentyp und den Produkten besteht), unbrauchbar, da er nur um die Einheit herumgemischt wird. Bei der Verwendung von jedoch echte Designentscheidungen getroffen werden . Hier ist ein Beispiel simpe, wobei bedeutet , dass wir in sind und bedeutet , dass wir in . Wenn wir aus extrahieren $\mathsf{Prop}$ $\mathsf{Prop}$ $\Sigma$ $\mathsf{Type}$ $\exists$ $\mathsf{Prop}$

Π n : N Σ b : {0, 1} Σ k : N n = 2 \cdot k + b

$\Pi_{n : \mathbb{N}} \Sigma_{b : \{0,1\}} \Sigma_{k : \mathbb{N}} \; n = 2 \cdot k + b$ we will get a program which decomposes

n $n$ into its lowest bit

b $b$ and the remaining bits

k $k$ , i.e., it computes everything. If we extract from

Π n : N Σ b : {0, 1} \exists k : N n = 2 \cdot k + b

$\Pi_{n : \mathbb{N}} \Sigma_{b : \{0,1\}} \exists_{k : \mathbb{N}} \; n = 2 \cdot k + b$ then the program will only compute the lowest bit

b $b$ . The machine cannot tell which is the correct one, the user has to tell it what he wants.

— Andrej Bauer
quelle

I'm slightly confused. Are you saying that without

Prop $\mathtt{Prop}$ it'd be impossible to recognize in the extracted program that

g(x) $g(x)$ doesn't contribute to the output (i.e. that it merely verifies it)? Are there scenarios where one wouldn't be able to pull out such useless code through the usual means available to code optimizers?

— user

From the extracted program one could say, "I want

k $k$ ," and backtrack from there. I haven't been able to come up with a scenario so entangled that we couldn't optimize away anything that doesn't directly contribute to determining the permutation without it in fact being necessary for computing said permutation (from a global optimization standpoint, anyway).

— user

You do not have the information "I want

k $k$ ". That is an extra assumption, and obviously once they tell you which particular result they want, you can just optimize away dead code. Actually, I thought of a better answer: it is a design question which things to put in

Prop $\mathsf{Prop}$ . You need to know what the user wants, and he tells you what he wants by using

Prop $\mathsf{Prop}$ . It is easy to come up with examples where there are several options. I will add one to my answer.

— Andrej Bauer

As far as I know nobody can really tell how to extract anything from

(−1) $(-1)$ -types. It's clear that they contain some computational content, but not what this might be.

— Andrej Bauer

Ah, okay. Using

Prop $\mathtt{Prop}$ as a way of specifying design decisions makes a lot more sense to me than as a way of deleting useless code.

— user

$\mathrm{Prop}$ is impredicative, which create a very expressive proof system. However it is "too" expressive in the following sense:

i m p r e d i c a t i v e P r o p + l a r g e e l i m i n a t i o n + e x c l u d e d m i d d l e

$\mathrm{impredicative\ Prop} + \mathrm{large\ elimination} + \mathrm{excluded\ middle}$

is inconsistent. Usually you want to keep the possibility to add the excluded middle, so one solution is to keep large elimination and make Prop predicative. The other is to suppress large elimination.

Coq did both! They renamed the predicative Prop to Set, and disabled large elimination in Prop.

The expressiveness gained by impredicativity is "reassuring" in the sense 99% of "reasonable" mathematics can be formalized with it, and it is known to be consistent relative to set theory. This makes it likely they won't weaken it to something like Agda, which only has predicative universes.

— cody
quelle

Oh and I forgot to mention: it is not the case that Prop : Prop, that would be inconsistent. Rather quantifications over all propositions is again a proposition.

— cody

Could you point me to any more resources about this? Everything I can find seems very scattered.

— user833970

@user833970 any specific things you'd like pointers to? I'm afraid there isn't really an all encompassing reference for meta theory of dependent types. This discussion (which points back here!) might be useful: github.com/FStarLang/FStar/issues/360

— cody

thank, I'm working through the Berardi paradox paper now, I think that will clear up my confusion.

— user833970

Even if you are not interested in extracting programs, the fact that Prop is impredicative allows you to build some models which you can't build using a predicative tower of universes. IIRC Thorsten Altenkirch has a model of System F using Coq's impredicativity.

— gallais
quelle