macchine von-Neumann e Lambda

Question

premessa di Brian nella sua argomentazione alla domanda "sono gli effetti collaterali di una cosa buona?" è interessante:

  

i computer sono macchine von Neumann che sono progettati per lavorare bene con gli effetti (piuttosto che essere progettato per funzionare bene con lambda)

Sono confuso dalla giustapposizione degli approcci. Non riesco a vedere come bianco e nero. Qual è la prova-valore:

  

i computer sono macchine von Neumann che sono progettati per lavorare bene con gli effetti [1]

L'ultima parte mi confonde:

  

piuttosto che essere progettato per funzionare bene con lambda [2]

sono la Lambda utilizzato come simboli per la programmazione funzionale? O sono euphenisms per la programmazione funzionale? Qual è il vero messaggio?

In che senso, le parti della premessa [1] e [2] sono di destra? Quali sono le premesse nascoste nella risposta? Qualcuno può giustificare la premessa originale? Come fanno le macchine von-Neumann e Lambda funzionano davvero?

Answer 1

Non sono del tutto sicuro di quello che stai chiedendo, ma come ho letto, si sta chiedendo cosa intende per lambda?

Si riferisce a lambda calcolo , che formano gran parte della base teorica per la programmazione funzionale . Si tratta di una notazione astratta per (tra l'altro) che descrivono e il ragionamento sulle funzioni di ordine superiore.

Una macchina di Von Neumann è fondamentalmente ciò che abbiamo. I programmi sono eseguiti da istruzioni manipolazione e di accesso a un negozio (la nostra RAM). Cioè, tutto è implicitamente fatto attraverso effetti collaterali. I dati vengono letti da qualche zona in RAM, elaborato un po ', e scritto di nuovo a qualche (altro forse,) Area nella RAM. Senza effetti collaterali, la CPU sarebbe limitato a manipolare qualsiasi dato spazzatura capitato di essere nei suoi registri, quando è stato acceso.

Lambda calcolo non ha alcuna nozione di effetti collaterali, quindi una macchina basata intorno a questo principio non avrebbe la distinzione tra "ciò che la CPU può accedere" (i nostri registri, essenzialmente), e "ciò che si può accedere indirettamente" (la nostra RAM ). Tutto in una macchina del genere sarebbe basa su principi di funzionamento, delle funzioni di prendere uno o più argomenti, e restituendo un nuovo valore, non modifica di quelle esistenti. (E no, io non sono sicuro di come dovrebbe funzionare in hardware ...:))

Ho risposto alla tua domanda?

Answer 2

Qui è più profonda di quello che I significava, anche se sarà interessante vedere se gli altri d'accordo o quello che hanno da dire.

Si consideri come funzionano i computer di oggi. Avete hardware che ha intere e in virgola mobile registri e una vasta gamma di memoria ad accesso casuale, e le istruzioni che sono per lo più di forma 'basato sulla lettura del valore di questa cella registro / memoria, andare colpire questo nuovo valore in questo registro /cellula'. (Aggiornamento celle di memoria ha una varietà di implicazioni Potenza quando si tratta di linee di cache e modelli di coerenza e di memoria e quant'altro.) Interi sono 32 o 64 bit, e quasi tutti i linguaggi di programmazione superficie questi tipi di dati che corrispondono esattamente l'hardware. Quasi ogni runtime funziona con una piccola pila chiamata in cui gli oggetti stack allocato sono economici, e più costoso 'mucchio' dove altri oggetti possono essere creati e distrutti quando base-non-stack-vite sono necessari.

Consideriamo ora più moderni linguaggi di programmazione funzionale. Immutabilità è la norma; raramente si 'colpire' di memoria con i nuovi valori. (Questo significa che si crea più nuovi oggetti, il che significa che allocare più.) Lambda e continuazioni sono la norma; più raramente hanno tempi di vita degli oggetti che corrispondono alla pila. (In effetti, alcuni tempi di esecuzione FP non usano uno stack, in un'implementazione CPS il concetto di stack e contatore di programma sono out-of-luogo.) La ricorsione è un costrutto iterativo, in modo da chiamate almeno necessita 'coda' di non consumare la pila comunque. Praticamente tutto ha bisogno di "cumulo" allocare, e, naturalmente, avete bisogno di un garbage-collector. I tipi di dati algebrici forniscono dati con tag; in teoria questi tag richiederebbero solo un supplemento di 2 o 3 bit di dati, ma in base al tempo di esecuzione, hanno spesso bisogno di avere una parola in più o più di memoria. ... Sto sorta di serpeggiante, ma le cose che il più delle volte in una lingua FP tendono a corrispondere esattamente alle cose che Scala peggiore o più costoso sulla tipica architettura hardware e language runtime di base.

Non deve essere in questo modo. Si può immaginare un mondo in cui il runtime rifugge una pila, e fa mucchio / allocazione veloce (e non un collo di bottiglia per le applicazioni multi-threaded). Si può immaginare un mondo in cui i tipi interi interoperabili hanno 29 o 60 bit, e utilizzare il runtime / hardware i bit extra rimanenti della parola per esempio GC, o tipo tag algebriche, o roba del genere. (Credo che alcune implementazioni FP / tempi di esecuzione fanno alcuni di questi trucchi.) Ecc ecc ... Il punto è che, se si prende un linguaggio moderno e funzionale come un dato di fatto, e quindi progettare runtime / hardware attorno ad esso, sarebbe un aspetto molto diverso dall'hardware tipica / tempi di esecuzione di oggi.

(non credo mi comunico che terribilmente, e io sono imprecise su molti dettagli che non conosco con precisione, ma spero che Grok il senso della mia tesi qui.)