I linguaggi di programmazione funzionale hanno più possibilità di eseguire l'ottimizzazione del tempo di compilazione?

I linguaggi di programmazione funzionale ottimizzano molto la compilazione dei tempi. Uno dei motivi è la purezza: la concorrenza è banale perché non esiste uno stato. Quindi il compilatore può prendere due rami e concurrenerli facilmente senza modificare il comportamento del programma.

Allo stesso tempo, tutto ciò che può essere calcolato senza stato (cioè tutto ciò che non è monadico in haskell) può essere calcolato in anticipo dal compilatore, ma tali calcoli potrebbero essere costosi e quindi probabilmente solo parzialmente.

Inoltre, tutto ciò che non è necessario a livello computazionale può essere completamente ottimizzato dal programma.

Che ci siano in linea di principio più possibilità di ottimizzazione del tempo di compilazione per i linguaggi funzionali che per le loro controparti imperative è probabilmente vero.

Più interessante è, se sono effettivamente implementati negli attuali compilatori e quanto rilevanti siano queste ottimizzazioni nella pratica (es. performance finale del codice idiomatico di "vita reale") in un ambiente di produzione, con impostazioni del compilatore predicibili a priori) .

es. le submissioni di Haskell per il famigerato gioco di benchmark per computer (male come potrebbe essere - ma non è così che c'è - a il momento - tutto ciò che è significativamente migliore là fuori) dà l'impressione che sia stata spesa una notevole quantità di tempo per le ottimizzazioni manuali, che confrontate con l'affermazione su "possibili ottimizzazioni del compilatore dovute a insert some property about FP languages here " fa sembrare che le ottimizzazioni siano (al momento almeno) più di una possibilità teorica rispetto a una realtà rilevante.

Sarei felice di essermi dimostrato sbagliato su questo punto.

In stile funzionale, il flusso di valori attraverso un programma è molto, molto visibile (sia per il compilatore che per il programmatore). Ciò conferisce al compilatore un ampio margine di manovra per decidere dove memorizzare i valori, quanto a lungo tenerli in giro e così via.

In un linguaggio imperativo, il compilatore promette al programmatore un modello in cui la maggior parte delle variabili corrispondono a posizioni reali nella memoria che restano intorno per una durata definita. Potenzialmente, qualsiasi affermazione può leggere da (o scrivere!) Qualsiasi di queste posizioni, quindi il compilatore può solo sostituire le posizioni di memoria con l'allocazione dei registri, unire due variabili in un'unica posizione di memoria, o eseguire ottimizzazioni simili dopo aver eseguito un'analisi accurata di dove altrimenti nel programma quella variabile può essere referenziata.

Ora ci sono due avvertimenti:

• La comunità del linguaggio di programmazione ha speso (sprecato?) un lotto di sforzi negli ultimi cinquant'anni sullo sviluppo di modi intelligenti per fare questa analisi. Ci sono trucchi ben noti come la colorazione dei registri e così via per ottenere alcuni dei casi più semplici fatti per la maggior parte del tempo; ma questo rende grandi, lenti compilatori e un compromesso costante di complessità di compilazione per la qualità del codice risultante
• Allo stesso tempo, la maggior parte dei linguaggi di programmazione funzionale non è puramente funzionale; molte delle cose che i programmi devono effettivamente fare, come rispondere agli I / O sono intrinsecamente non funzionali, quindi nessun compilatore può essere completamente libero da questi trucchi, e nessun linguaggio li evita del tutto - anche Haskell, che è un po '< em> too puro per i miei gusti (Your Mileage May Vary) può solo controllare e rimuovere le parti non funzionali del tuo codice, non evitarle del tutto.

Ma per rispondere alla domanda generale, sì, un paradigma funzionale dà al compilatore molta libertà di ottimizzare che non ha in un'impostazione imperativa.