I compilatori di interi programmi come MLton creano binari ottimizzati in parte per la loro capacità di utilizzare la fonte totale del binario per eseguire una valutazione parziale: allineare in modo aggressivo le costanti e valutarle fino a bloccarle durante la compilazione!GHC Valutazione parziale e compilazione separata
Questo è stato esplorato pubblicamente un po 'nello spazio Haskell di Gabriel Gonzalez's Morte.
Ora la mia comprensione è che Haskell non fa molto di questo, se non del tutto. Il motivo citato che capisco è che è antitetico separare la compilazione. Questo ha senso proibire la valutazione parziale tra i limiti del file sorgente, ma sembra che la valutazione parziale del file sarebbe comunque un'opzione.
Per quanto ne so, la valutazione parziale nel file non viene comunque eseguita.
La mia domanda è: è vero? In tal caso, quali sono i compromessi per l'esecuzione della valutazione parziale in-file? In caso contrario, cos'è un file di esempio in cui è possibile migliorare le prestazioni compilate inserendo più funzionalità nello stesso file?
(Modifica: per chiarire quanto sopra, so che ci sono molte domande su quale sia la migliore serie di riduzioni da eseguire - molte sono indecidibili! Mi piacerebbe sapere i compromessi fatti in una "forza industriale" "compilatore con una compilazione separata che vive ad un livello superiore scegliendo la giusta teoria equazionale se ci sono cose interessanti di cui parlare. Cose come la velocità di compilazione o il file gonfiato sono più verso lo scopo a cui sono interessato. Un'altra domanda nello stesso lo spazio potrebbe essere: "Perché MLton non può ottenere una compilazione separata semplicemente compilando ciascun modulo separatamente, lasciando l'API esposta e quindi collegandoli tutti insieme?")
La cosa di valutazione parziale è che soffre del problema della terminazione. Quando decidi di interrompere parzialmente la valutazione di un'espressione? Ad esempio, prendi l'espressione 'enumFrom 0: [Intero]'. Se provi a valutare parzialmente il tuo compilatore non finirà mai, il che è una cosa molto brutta. Una soluzione potrebbe essere quella di non valutare le espressioni nella forma normale della testa debole. Tuttavia ciò significherebbe che determinate espressioni non sarebbero ottimizzabili. La riscrittura è un modo rapido e sporco per superare la deforestazione delle strutture di dati intermedi. Inoltre termina. Il problema è la correttezza. –
Il Glasgow Haskell Compiler esegue inline, anche se non in modo aggressivo: http://stackoverflow.com/q/26996110/783743. Sembra che molte persone si interessino all'inlinazione aggressiva: http://stackoverflow.com/questions/26827663/rewriting-as-a-practical-optimization-technique-in-ghc-is-it-really-needed . Il mio ultimo anno di studi di Bachelor prevede la riscrittura e la valutazione parziale in linguaggi di programmazione funzionale. –
Dovrei aggiungere alla domanda per essere più chiaro.Sono consapevole che molte uguaglianze qui sono indecidibili (e potrebbe essere peggiore in Haskell che in ML), ma MLton è una prova dell'esistenza (parziale) che c'è una riduzione dell'eguaglianza che è sia benefica che terminante. Senza esaminare troppo profondamente quali sono le riduzioni giuste da eseguire, mi piacerebbe avere il ragionamento per implementarle in un compilatore di "forza industriale" con compilazione separata. –