Quali sono le implicazioni pratiche della teoria dei tipi di omotopia nella programmazione?


11

Sto appena iniziando a imparare Haskell, dopo essere venuto dai mondi JavaScript / Ruby. Mi sono imbattuto in https://github.com/HoTT e nel libro Homotopy Type Theory , che non vedo l'ora di leggere.

Tuttavia, imparerò i concetti di matematica e teoria dei tipi man mano che procederò, quindi sembra che ci vorrà molto tempo prima di capire cosa significherà la teoria dei tipi di omotopia per un programmatore praticante.

Potresti descrivere quale impatto avrà la teoria del tipo di omotopia sulla programmazione in pratica, per un laico? Ad esempio, renderà alcune cose più facili da scrivere? In tal caso, quali cose? O ti consentirà di fare nuove cose nella programmazione che prima non erano possibili? In tal caso, quali cose?

Grazie, non vedo l'ora di avvolgerci la testa a un livello più elementare.


Mi aspetto che lo sia, e rimarrà sempre imperscrutabile per i programmatori praticanti. Nella migliore delle ipotesi, potremmo ottenere compilatori più veloci o scatole nere magiche che sfruttano il fu matematico.
Telastyn,

Haha questo è quello che ho pensato fino ad ora. Mi chiedo ancora, è questa la risposta o c'è qualcosa al di là di quello che hai detto? Ad esempio, i database potrebbero trarne vantaggio? O qualcosa del genere.
Lance Pollard,

1
Non ne ho idea. Ho letto l'abstract e l'ho lasciato cadere prontamente nel secchio per imperscrutabili mumbo-jumbo accademici.
Telastyn,


4
@Telastyn: se scarichi un libro in portoghese, sarà anche imperscrutabile fino a quando non avrai provato ad imparare la lingua. Perché denunciare pubblicamente i libri portoghesi con il termine dispregiativo mumbo-jumbo ? La motivazione di Gödels per l'introduzione di funzioni ricorsive primitive era estremamente accademica, in particolare perché il mondo non aveva nemmeno avviato programmi negli anni '30. Non credo solo perché uno è un programmatore praticante, gli argomenti accademici "rimarranno sempre imperscrutabili" per le tue capacità.
Nikolaj-K,

Risposte:


15

Una delle cose potenti che i compilatori sono in grado di fare durante la loro fase di ottimizzazione è di scambiare rappresentazioni inefficienti con equivalenti. Ad esempio, in Haskell è possibile utilizzare un elenco pigro per calcolare una somma di numeri, ma il compilatore GHC Haskell riconoscerà che ciò equivale a utilizzare l'iterazione con una variabile temporanea. In questo modo, puoi programmare contro una semplice astrazione di cui è facile ragionare, mentre il tuo eseguibile sfrutta una rappresentazione più adatta alla piattaforma hardware (e che risulta essere molto più difficile da ragionare su larga scala).

Tuttavia, le equivalenze note al compilatore sono per lo più limitate a strutture di dati ben note e ricercate, come la fusione di flussi per elenchi. Potresti definire le tue equivalenze nel codice sorgente (usando una coppia di funzioni di conversione che compongono l'identità in entrambe le direzioni), ma dovresti applicarle manualmente e può essere difficile scegliere il tipo giusto da usare in tutti i luoghi al fine di evitare conversioni eccessive.

Ora immaginiamo un mondo in cui puoi definire "tipi induttivi superiori", diciamo una mappa di ricerca canonica. Questo tipo ha diversi costruttori per i vari tipi di mappe: ricerca binaria, AVL, rosso-nero, Trie, Patricia, ecc. Insieme ai costruttori di dati tipici, si definisce anche un tipo di equivalenza che acquisisce eventualmente più conversioni tra queste rappresentazioni, dove diverse le conversioni offrono diverse dimensioni di efficienza (ovvero tempo rispetto alla memoria).

E se il compilatore fosse in grado di utilizzare questa nozione per riscrivere in modo trasparente le rappresentazioni delle mappe, come può fare oggi con la fusione di elenchi? Nel frattempo, nel tuo codice puoi lavorare con la costruzione che è più semplice ragionare (e semplifica il lavoro di prova, se ti trovi in ​​un ambiente simile). Può sembrare un'interfaccia astratta con più implementazioni, ma include la libertà di scegliere qualsiasi implementazione e far sì che il compilatore ne sostituisca in modo trasparente un altro secondo necessità, senza influire sul significato del programma.

HoTT ci fornisce una base teorica di tipo per giustificare questo meccanismo di riscrittura di fantasia e questi tipi ben definiti, perché promuove la nozione di equivalenza ad essere equivalente all'uguaglianza. Resta da vedere come questo si realizzerà nella pratica, ma ci fornisce il quadro teorico su cui basare il lavoro futuro.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.