Relazione tra teoria dei tipi russelliana e sistemi di tipi

Di recente mi sono reso conto che esiste una sorta di relazione tra la teoria dei tipi russelliana e i sistemi di tipi, come ad esempio trovato in Haskell. In realtà, alcune delle notazioni per tipi in Haskell sembrano avere precursori nella teoria dei tipi. Ma, IMHO, la motivazione di Russell nel 1908 fu quella di evitare il paradosso di Russell, e non sono sicuro di come questo sia legato ai sistemi di tipo nell'informatica.

Il paradosso di Russell in una forma o nell'altra è qualcosa di cui dovremmo preoccuparci, ad esempio, se non avessimo un buon sistema di tipi in una determinata lingua?

`` Teoria dei tipi "nel senso dei linguaggi di programmazione e nel senso di Russell sono strettamente correlati. In effetti, il campo moderno della teoria dei tipi dipendenti mira a fornire basi costruttive per la matematica. A differenza della teoria degli insiemi, la maggior parte delle ricerche basate sulla teoria dei tipi la matematica viene eseguita in assistenti di prova come Coq, NuPRL o Agda. In quanto tali, le prove eseguite in questi sistemi non sono solo "formalizzabili" ma in realtà completamente formali e controllate a macchina. Usando tattiche e altre tecniche di automazione delle prove, cerchiamo di dimostrare i sistemi "di alto livello" e quindi assomigliano alla matematica informale, ma poiché tutto è controllato abbiamo garanzie molto migliori sulla correttezza.

Vedi qui

I tipi nei comuni linguaggi di programmazione tendono ad essere più limitati, ma la meta-teoria è la stessa.

Qualcosa di simile al paradosso di Russell è un grosso problema nella teoria dei tipi dipendenti. In particolare, avendo

Type : Type

di solito porta alla contraddizione. Coq e lavori simili nidificando gli universi

Type_0 : Type_1

ma in Coq di default questi numeri sono impliciti in quanto normalmente non contano per il programmatore.

In alcuni sistemi (Agda, Idris), la regola di tipo nel tipo è abilitata tramite un flag di compilazione. Rende le logiche incoerenti, ma spesso facilita la programmazione / dimostrazione esplorativa.

Anche in lingue più tradizionali, il paradosso di Russell si presenta occasionalmente. Ad esempio, in Haskell è possibile una codifica del paradosso di Russell che combina impredicatività e caso di tipo aperto, consentendo di costruire termini divergenti senza ricorsione anche a livello di tipo. Haskell è `` incoerente "(quando interpretato come una logica nel solito modo) poiché supporta la ricorsione sia a livello di tipo che di valore, per non parlare delle eccezioni. Tuttavia, questo risultato è piuttosto interessante.

Hai ragione sulla motivazione di Russell. Il suo paradosso affligge tutte le teorie degli insiemi che ammettono assiomi di comprensione senza restrizioni per l'effetto che: qualsiasi funzione proposizionale determina un insieme, cioè quello di tutte quelle entità che soddisfano la funzione. Tra le teorie di o basate su insiemi che avevano quel difetto c'erano la teoria ingenua degli insiemi di Cantor e il sistema di Grundgesetze di Frege (in particolare: assioma 5).

Poiché i tipi sono considerati tipi speciali di insiemi, se non si presta attenzione, un simile paradosso può insinuarsi in un sistema di tipi. Detto questo, non sono a conoscenza di alcun sistema di tipi che ha subito un destino simile. Posso solo ricordare i primi tentativi della Chiesa di formulare il calcolo lambda negli anni '30, che si rivelò incoerente (paradosso di Kleene-Rosser), ma che uno non era né dovuto ai tipi né era correlato al paradosso di Russell.

Aggiornamento : vedi la risposta di Philip per una risposta effettiva alla tua domanda.

Dato che menzioni Python, la domanda non è puramente teorica. Quindi provo a dare una prospettiva più ampia sui tipi. I tipi sono cose diverse per persone diverse. Ho raccolto almeno 5 nozioni distinte (ma correlate) di tipi:

1. I sistemi di tipo sono sistemi logici e impostano teorie.

2. Un sistema di tipi associa un tipo a ciascun valore calcolato. Esaminando il flusso di questi valori, un sistema di tipi tenta di provare o garantire che non si possano verificare errori di tipo.

3. Tipo è una classificazione che identifica uno dei vari tipi di dati, come valori reali, numeri interi o booleani, che determina i possibili valori per quel tipo; le operazioni che possono essere eseguite su valori di quel tipo; il significato dei dati; e il modo in cui i valori di quel tipo possono essere memorizzati

4. I tipi di dati astratti consentono l'astrazione dei dati in linguaggi di alto livello. Gli ADT sono spesso implementati come moduli: l'interfaccia del modulo dichiara procedure che corrispondono alle operazioni ADT. Questa strategia di occultamento delle informazioni consente di modificare l'implementazione del modulo senza disturbare i programmi client.

5. Le implementazioni del linguaggio di programmazione utilizzano tipi di valori per scegliere la memoria necessaria per i valori e gli algoritmi per le operazioni sui valori.

Le citazioni provengono da Wikipedia, ma posso fornire riferimenti migliori in caso di necessità.

I tipi 1 sono nati dal lavoro di Russel, ma oggi non sono semplicemente protetti dai paradossi: il linguaggio tipizzato della teoria dei tipi di omotopia è un nuovo modo per codificare la matematica in un linguaggio formale comprensibile dalla macchina e un nuovo modo per gli umani di comprendere le basi di matematica. (Il "vecchio" modo è codificare usando una teoria degli assiomatici).

I tipi 2-5 sono nati nella programmazione da diverse esigenze: evitare bug, classificare i progettisti e programmatori di software di dati con cui lavorare, progettare sistemi di grandi dimensioni e implementare i linguaggi di programmazione in modo efficiente rispettivamente.

I sistemi di tipo in C / C ++, Ada, Java, Python non sono nati dal lavoro di Russel o dal desiderio di evitare bug. Nacquero per necessità di descrivere diversi tipi di dati là fuori (es. "Il cognome è una stringa di caratteri e non un numero"), modularizzare la progettazione del software e scegliere rappresentazioni di basso livello per i dati in modo ottimale. Queste lingue non hanno tipi-1 o tipi-2. Java garantisce la relativa sicurezza dai bug non dimostrando la correttezza del programma usando il sistema dei tipi, ma attraverso un'attenta progettazione del linguaggio (senza aritmetica del puntatore) e del sistema di runtime (macchina virtuale, verifica del bytecode). Il sistema di tipi in Java non è né un sistema logico né una teoria dell'insieme.

Tuttavia, il sistema di tipi nel linguaggio di programmazione Agda è una variante moderna del sistema di tipi di Russel (basato sul lavoro successivo o su Per Martin-Lof e altri matematici). Il sistema di tipi in Agda è progettato per esprimere le proprietà matematiche del programma e delle prove di tali proprietà, è un sistema logico e una teoria dell'insieme.

Non ci sono distinzioni bianco-nero qui: molte lingue si incastrano tra loro. Ad esempio, il sistema di tipi del linguaggio Haskell ha radici nel lavoro di Russel, può essere visto come un sistema Agda semplificato, ma dal punto di vista matematico, è incoerente (contraddittorio) se visto come un sistema logico o una teoria dell'insieme.

Tuttavia, come veicolo teorico per proteggere i programmi Haskell dai bug, funziona abbastanza bene. È anche possibile utilizzare i tipi per codificare determinate proprietà e le relative prove, ma non tutte le proprietà possono essere codificate e il programmatore può comunque violare le proprietà dimostrate se utilizza hack sporchi scoraggiati.

Il sistema di tipi di Scala è ancora più lontano dal lavoro di Russel e dal linguaggio di prova perfetto di Agda, ma ha ancora radici nel lavoro di Russel.

Per quanto riguarda la dimostrazione delle proprietà dei linguaggi industriali i cui sistemi di tipi non sono stati progettati per questo, ci sono molti approcci e sistemi.

Per approcci interessanti ma diversi, vedi il progetto di ricerca Coq e Microsoft Boogie. Coq si affida alla teoria dei tipi per generare programmi imperativi dai programmi Coq. Boogie si basa sull'annotazione di programmi imperativi con proprietà e sulla dimostrazione di quelle proprietà con il proverore di teoremi Z3 usando un approccio completamente diverso rispetto a Coq.