Perché Coq ha Prop?

Coq ha un tipo Prop di proposizioni irrilevanti che vengono scartate durante l'estrazione. Quali sono i motivi per avere questo se usiamo Coq solo per prove. Prop è impredicativo, ~~quindi Prop: Prop,~~ tuttavia, Coq infetta automaticamente gli indici dell'universo e possiamo usare il Tipo (i) invece ovunque. Sembra che Prop complica molto tutto.

Ho letto che ci sono ragioni filosofiche per separare Set e Prop nel libro di Luo, tuttavia non li ho trovati nel libro. Quali sono?

coq dependent-type

— Konstantin Solomatov
fonte

"Se usiamo Coq solo per prove": penso che tu abbia identificato un punto chiave qui. Coq non viene utilizzato solo per le prove.

— Gilles 'SO-smetti di essere malvagio' il

Risposte:

è molto utile per l'estrazione del programma perché ci consente di eliminare parti di codice inutili. Ad esempio, per estrarre un algoritmo di ordinamento proveremmo l'affermazione "per ogni elenco esiste un elenco tale che è ordinato e è un permutatiom di ". Se lo scriviamo in Coq ed estraiamo senza usare $\mathtt{Prop}$ $\ell$ $k$ $k$ $k$ $\ell$ , otterremo: $\mathtt{Prop}$

"per tutti c'è " ci darà una mappa che porta gli elenchi in elenchi, $\ell$ $k$ sort
"tale che sia ordinato" fornirà una funzione che attraversa e verifica che sia ordinato, e $k$ verify $k$
" è una permutazione di " darà una permutazione che prende da a . Si noti che non è solo una mappatura, ma anche la mappatura inversa insieme ai programmi che verificano che le due mappe siano realmente inverse. $k$ $\ell$ pi $\ell$ $k$ pi

Mentre le cose extra non sono del tutto inutili, in molte applicazioni vogliamo liberarcene e mantenerci giuste sort. Questo può essere realizzato se usiamo per indicare " è ordinato" e " è una permutazione di ", ma non "per tutti $\mathtt{Prop}$ $k$ $k$ $\ell$ c'è ". $\ell$ $k$

In generale, un modo comune per estrarre il codice è quello di considerare un'istruzione del modulo dove è input, è output e spiega cosa significa che è un output corretto. (Nell'esempio precedente e sono i tipi di elenchi e è " è ordinato e è una permutazione di .") Se è in estrazione fornisce una mappa $\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}$ tale che $f : A \to B$ vale per ogni . Se è in otteniamo anche una funzione tale che è la prova che vale, per tutti $\phi(x, f(x))$ $x \in A$ $\phi$ $\mathtt{Set}$ $g$ $g(x)$ $\phi(x, f(x))$ $x \in A$ . Spesso la prova è inutilmente computazionale e preferiamo liberarcene, specialmente quando è annidata profondamente in qualche altra affermazione. ci dà la possibilità di farlo. $\mathtt{Prop}$

Aggiunto 2015/07/29: V'è un problema se potremmo evitare complessivamente ottimizzando automaticamente via "codice estratto inutile". In una certa misura possiamo farlo, ad esempio tutto il codice estratto dal frammento negativo della logica (materiale creato dal tipo vuoto, tipo di unità, prodotti) è inutile in quanto si sposta semplicemente attorno all'unità. Ma ci sono autentiche decisioni di progettazione che bisogna prendere quando si usa . Ecco un esempio semplice, in cui significa che siamo in e significa che siamo in $\mathsf{Prop}$ $\mathsf{Prop}$ $\Sigma$ $\mathsf{Type}$ $\exists$ $\mathsf{Prop}$ . Se estraiamo da otterremo un programma che decompone nel suo bit più basso e i rimanenti bit , ovvero calcola tutto. Se estraiamo da

Π_{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$

n

$n$

b

$b$

k

$k$

il programma calcolerà solo il bit più basso

. La macchina non può dire quale sia quella corretta, l'utente deve dirgli quello che vuole.

Π_{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$

b

$b$

— Andrej Bauer
fonte

Sono leggermente confuso. Stai dicendo che senza

sarebbe impossibile riconoscere nel programma estratto che

non contribuisce all'output (cioè che si limita a verificarlo)? Ci sono scenari in cui non si sarebbe in grado di estrarre tale codice inutile attraverso i soliti mezzi disponibili per gli ottimizzatori di codice?

P r o p

$\mathtt{Prop}$

g (x)

$g(x)$

— utente

Dal programma estratto si potrebbe dire "Voglio

" e tornare indietro da lì. Non sono stato in grado di escogitare uno scenario così intricato che non potremmo ottimizzare nulla che non contribuisca direttamente a determinare la permutazione senza che sia effettivamente necessario per calcolare detta permutazione (dal punto di vista dell'ottimizzazione globale, comunque ).

k

$k$

— utente

Non hai l'informazione "Voglio

". Questo è un presupposto extra, e ovviamente una volta che ti dicono quale risultato particolare vogliono, puoi semplicemente ottimizzare il codice morto. In realtà, ho pensato a una risposta migliore: è una domanda di design che le cose da mettere in

. Devi sapere cosa vuole l'utente e ti dice cosa vuole usando

. È facile trovare esempi in cui esistono diverse opzioni. Ne aggiungerò uno alla mia risposta.

k

$k$

P r o p

$\mathsf{Prop}$

P r o p

$\mathsf{Prop}$

— Andrej Bauer,

Per quanto ne so nessuno può davvero dire come estrarre qualsiasi cosa da

tipi. È chiaro che contengono alcuni contenuti computazionali, ma non quello che potrebbe essere.

(- 1)

$(-1)$

— Andrej Bauer,

Ah ok. Usare

come un modo per specificare le decisioni di progettazione ha molto più senso per me che come un modo di eliminare il codice inutile.

P r o p

$\mathtt{Prop}$

— utente

èimpredicativo, che crea un sistema di prove molto espressivo. Tuttavia è "troppo" espressivo nel senso seguente: $\mathrm{Prop}$

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}$

è incoerente. Di solito si desidera mantenere la possibilità di aggiungere il centro escluso, quindi una soluzione è mantenere l'eliminazione di grandi dimensioni e rendere predicativo Prop. L'altro è sopprimere l'eliminazione di grandi dimensioni.

Coq ha fatto entrambe le cose! Hanno rinominato il predicativo Prop in Set e disabilitato l'eliminazione di grandi dimensioni in Prop.

L'espressività acquisita dall'impedicatività è "rassicurante", nel senso che il 99% della matematica "ragionevole" può essere formalizzata con essa, ed è noto che è coerente rispetto alla teoria degli insiemi. Questo rende probabile che non lo indeboliranno in qualcosa come Agda, che ha solo universi predicativi.

— cody
fonte

Oh, e ho dimenticato di dire: è non è il caso che Prop : Prop, che sarebbe incoerente. Piuttosto le quantificazioni su tutte le proposizioni sono di nuovo una proposizione.

— cody

Potresti indicarmi altre risorse su questo? Tutto quello che riesco a trovare sembra molto sparso.

— user833970

@ user833970 delle cose specifiche che vorresti puntatori? Temo che non ci sia davvero un riferimento onnicomprensivo per la meta-teoria dei tipi dipendenti. Questa discussione (che indica qui!) Potrebbe essere utile: github.com/FStarLang/FStar/issues/360

— cody

grazie, sto lavorando al documento sul paradosso di Berardi ora, penso che chiarirà la mia confusione.

— user833970

Anche se non sei interessato ad estrarre programmi, il fatto che Propsia impredicativo ti consente di costruire alcuni modelli che non puoi costruire usando una torre predicativa di universi. IIRC Thorsten Altenkirch ha un modello di Sistema F che utilizza l'impredicatività di Coq.

— Gallais
fonte