Risposte:
Ohad ha ragione sui problemi che il calcolo lambda deve affrontare come base per parlare di classi di complessità. C'è stato un bel po 'di lavoro fatto per caratterizzare la complessità della riducibilità nel calcolo lambda, in particolare per quanto riguarda il lavoro sulla riduzione etichettata e ottimale della tesi di dottorato di Lèvy. In generale, i buoni modelli di costo per il calcolo lambda non dovrebbero assegnare un peso costante a tutte le riduzioni beta: intuitivamente, sostituire un grande sotteraneo in molti luoghi con scopi diversi dovrebbe costare di più che contrarre un piccolo redex K, e se si desidera un certo importo di invarianza dei costi in diverse strategie di riscrittura, questo diventa essenziale.
Due collegamenti:
Per qualcosa di più vicino alla tua domanda, esiste un progetto attuale che sviluppa e studia un sistema di tipo (un linguaggio di programmazione funzionale) che mediante analisi statica può determinare limiti (polinomiali) di runtime di programmi (così come altre risorse utilizzate da programmi). Quindi, in un certo senso, ciò potrebbe suggerire che potrebbe esserci qualche vantaggio nell'uso della programmazione funzionale per l'analisi della complessità del runtime. La homepage del progetto è qui .
Un documento forse rappresentativo di questo progetto è: Jan Hoffmann, Martin Hofmann. Analisi delle risorse ammortizzate con potenziale polinomiale - Un'inferenza statica dei limiti polinomiali per i programmi funzionali. In Atti del XIX Simposio europeo sulla programmazione (ESOP'10). collegamento
C'è una linea di lavoro molto interessante basata sulla logica lineare, chiamata teoria della complessità implicita, che caratterizza varie classi di complessità imponendo varie discipline di tipo sul calcolo lambda. IIRC, questo lavoro è iniziato quando Bellantoni e Cook e Leivant hanno scoperto come utilizzare il sistema dei tipi per legare la ricorsione primitiva per catturare varie classi di complessità.
In generale, l'attrazione a lavorare con i calcoli lambda è che a volte è possibile trovare caratterizzazioni più estensive (cioè più matematicamente trattabili) di varie caratteristiche intensionali che danno ai modelli come le macchine di Turing il loro potere. Ad esempio, una differenza tra le macchine di Turing e il puro calcolo lambda è che, poiché Turing riceve codici di programmi, un client può implementare manualmente i timeout, implementare a coda di rondine - e quindi può calcolare parallelo o. Tuttavia, i timeout possono anche essere modellati metricamente ed Escardo ha ipotizzato (non conosco il suo stato) che i modelli di spazio metrico del calcolo lambda siano completamente astratti per i timeout PCF +. Gli spazi metrici sono oggetti matematici molto ben studiati ed è molto bello poter usare quel corpus di teoria.
Tuttavia, la difficoltà di usare il calcolo lambda è che ti costringe ad affrontare fenomeni di ordine superiore fin dal cancello di partenza. Questo può essere molto sottile, poiché la tesi di Church-Turing fallisce nel tipo superiore - i modelli naturali di calcolo differiscono nel tipo superiore, poiché differiscono in ciò che ti è permesso fare con le rappresentazioni dei calcoli. (Parallelo-o è un semplice esempio di questo fenomeno, poiché mostra una differenza tra LC e TM.) Inoltre, non c'è nemmeno una stretta inclusione tra i diversi modelli, poiché la contraddizione dello spazio delle funzioni significa che un potere più espressivo ad un ordine implica meno potere espressivo un ordine più alto.
Per quanto ne so, il calcolo lambda non è adatto a questo scopo, poiché la nozione di complessità tempo / spazio è difficile da formulare nel calcolo lambda.
Cos'è 1 unità di complessità temporale? Una riduzione beta? E le unità di complessità spaziale? La lunghezza della corda?
Il calcolo lambda è più adatto alla manipolazione astratta degli algoritmi, poiché è molto più facilmente componibile rispetto alle macchine di Turing.
Potresti anche cercare calcoli di sostituzioni esplicite che suddividono la sostituzione a meta-livello del calcolo lambda in una serie di passaggi di riduzione esplicita. Ciò tocca il punto di Charles che tutte le sostituzioni non dovrebbero essere considerate uguali quando si considera la complessità temporale.
Vedi Nils Anders Danielsson, Analisi della complessità temporale semiforme leggera per strutture di dati puramente funzionali che viene implementata come libreria in Agda. Anche le citazioni riportate nel documento sembrano molto promettenti.
Un aspetto chiave per me è che è appropriato / utile / ragionevole / semi-automatizzabile derivare la complessità temporale degli algoritmi nel calcolo lambda semplicemente tipizzato soprattutto se quegli algoritmi sono facilmente espressibili in esso (cioè puramente funzionali) e soprattutto se quelli gli algoritmi fanno un uso essenziale, ad esempio, della semantica call-by-name. Insieme a questo è probabilmente il punto evidente che non si calcola la complessità solo "nel calcolo lambda" ma nel calcolo lambda in una data strategia di valutazione.