2009-12-06 10 views
13

Esiste l'intero nuovo paradigma della "programmazione funzionale", che richiede un cambiamento totale dei modelli di pensiero rispetto alla programmazione procedurale. Usa funzioni di ordine superiore, purezza, monade, ecc., Che di solito non vediamo nei linguaggi imperativi e orientati agli oggetti.Come il linguaggio funzionale è diverso dal punto di vista dell'implementazione del linguaggio

mia domanda è come la realizzazione di queste lingue differisce da linguaggi imperativi o orientati agli oggetti, per quanto riguarda, ad esempio, la gestione della memoria o interni come puntatori ecc ..

Ci sono linguaggi funzionali che girano su in cima alla JVM. Questo significa che queste lingue funzionano internamente come le altre lingue sulla JVM?

+8

Solo nitpick: non definirei FP come un "nuovo paradigma" ... (solo leggermente più popolare di prima forse) –

risposta

5

Le implementazioni dei linguaggi di programmazione funzionale utilizzano un'ampia gamma di tecniche di implementazione. Un'ottima introduzione all'implementazione di Scheme (un dialetto Lisp) dà questo libro: Lisp in Small Pieces di Christian Queinnec.

0

Tutto gira sullo stesso processore (e quindi le stesse istruzioni di assemblaggio), quindi se vai abbastanza in profondità, tutto è lo stesso internamente.

+3

Non sono esperto in questo settore, ma il fatto che tutto funzioni sullo stesso assembly le istruzioni (x86/x86_64) sembrano essere più il risultato del dominio dell'architettura x86. C'erano, nel corso della giornata, macchine Lisp con processori progettati appositamente per Lisp. http://en.wikipedia.org/wiki/Lisp_machine –

+0

Sicuro. Ma mi riferivo di più al fatto che supponendo che tu stia utilizzando tutti i tipi di linguaggi sulla stessa piattaforma, a un certo livello o in un altro, tutto si ridurrà alla stessa cosa. (Funzionale, procedurale, basato su logica, ecc.) – Amber

+4

Questo non ha senso. Un compilatore Lisp è implementato in modo diverso da un compilatore C, utilizza sequenze di istruzioni diverse e compila a sequenze di istruzioni diverse. che tutti i veicoli auto sulla stessa strada non fanno tutte le auto sguardo o funzionano allo stesso modo. Alcuni hanno due ruote, altri quattro, ecc. Ecc. –

1

Credo che ci sono molti aspetti che beneficiano di una particolare attenzione in linguaggi funzionali, uno che viene in mente è:

linguaggi funzionali utilizzano la ricorsione molto. Quindi qualsiasi implementazione dovrebbe cercare di ottimizzare questo caso. Per esempio. identificare la ricorsione in coda e trasformarla in un loop internamente (risparmiando così i costi di chiamata delle funzioni come stack save/restore). (http://en.wikipedia.org/wiki/Tail_recursion)

+0

sì, ovviamente ci sono vantaggi e alcuni svantaggi del FP, ma la domanda riguarda il loro funzionamento interno. – dinsim

1

L'implementazione di un linguaggio di programmazione funzionale come Haskell è spesso molto diversa da quella delle lingue imperative. Puoi leggere un modo per farlo, here. Anche se il giornale ha diversi anni, credo che le idee siano ancora utilizzate.

+0

Mentre quel libro è un po 'vecchio, è comunque un'ottima lettura. Per me è stata una vera esperienza dell'AHA nella bellezza dell'implementazione di linguaggi funzionali. – rvirding

8

Il codice risultante dai linguaggi funzionali utilizza molte funzioni che si vedono in gradi diversi nelle lingue non funzionanti. La raccolta dei rifiuti è passata all'utilizzo generale. L'ottimizzazione della chiamata di coda è done in GCC and VC++.

Le chiusure, tuttavia, sono un segno distintivo della programmazione funzionale. Non si vede l'uno senza l'altro. Se definisci i "linguaggi funzionali" per riferirsi solo ai linguaggi funzionali puri, i due non sono sinonimi di chiusure in linguaggi imperativi che supportano la programmazione funzionale (ad es. Javascript e Scheme (che è tecnicamente imperativo, sebbene il paradigma funzionale sia quello per lo più Usato)). Le chiusure potrebbero essere implementate con uno spaghetti stack per lo stack di chiamate o copiando le variabili locali quando si esce da uno stack frame o allocando variabili locali sull'heap e lasciando che la garbage collection si occupi di esse.

Una volta terminate le chiusure, le funzioni anonime sono relativamente facili (con un interprete, sono davvero facili). Con un compilatore, la funzione viene convertita in bytecode in fase di compilazione e il bytecode (piuttosto l'indirizzo del punto di ingresso) viene associato in fase di runtime all'ambiente corrente.

La composizione delle funzioni può fare affidamento sulla funzione anonima. Quando un compilatore incontra un operatore di composizione di funzioni f . g, crea una funzione anonima che chiama i due argomenti f e g, passando il risultato di uno come argomento all'altro.

Le Monade possono essere implementate in lingue OO, non sono tanto necessarie quanto in lingue puramente funzionali.Le monade I/O non sono niente di speciale, si basano solo sul fatto che la piattaforma sottostante consente effetti collaterali.

1

La più grande differenza che viene in mente è che i linguaggi funzionali tendono ad essere progettati in modo che il codice sorgente sia desugared in un linguaggio intermedio matematicamente semplice e potente. Questa lingua di solito contiene lambda, chiamate di funzione, se/else, tipi di macchine, qualcosa come let, e non molto di più. Il codice trasformato è profondamente annidato, prolisso e non realisticamente leggibile. La sintassi della superficie viene gettata via.

Un compilatore per un linguaggio come questo ha a che fare un po 'messa in linea e un paio di ottimizzazioni di chiusura per la produzione di codice decente. (Per me queste ottimizzazioni di chiusura di base sembrano non banali - analisi di fuga e così via - ma potrebbe essere solo mancanza di familiarità.)

0

@outis: Mentre la lingua può supportarle, le chiusure sono in conflitto con il concetto matematico di un funzionano allo stesso modo degli effetti collaterali: ti permettono di ottenere risultati diversi dagli stessi argomenti. Ciò rende le chiusure procedurali, piuttosto che funzionali.

Detto questo, ci sono argomenti di efficienza che favoriscono la chiusura oltre globali (in particolare nel contesto della realizzazione del compilatore). [Ma conosco i linguaggi funzionali che non forniscono le chiusure direttamente, anche se possono essere implementate "aliquote di lavoro".]

(Tuttavia, il curring è simile alle chiusure e non soffre di questo conflitto, ed è infatti abitualmente presente in linguaggi funzionali.)

in ogni modo, a mio parere, i linguaggi di programmazione funzionali sono lingue che fanno grandi sforzi per rendere il calcolo sia rappresentabile come se fossero funzioni matematiche. Ciò significa che le ottimizzazioni sono inclinate all'ottimizzazione delle funzioni.

Ipoteticamente, almeno, linguaggi funzionali permettono alla macchina di lavorare su astrazioni più profonde di quanto sarebbe utile per un approccio puramente procedurale.