von-Neumann máquinas y Lambdas

Question

Brian premisa de su argumento a la pregunta "Son los efectos secundarios de una cosa buena?" es interesante:

los equipos son de von-Neumann máquinas que se han diseñado para trabajar bien con los efectos (en lugar de ser diseñado para trabajar bien con las lambdas)

Estoy confundido por la yuxtaposición de los enfoques.No los puedo ver en blanco y negro.¿Cuál es la prueba de valor de:

los equipos son de von-Neumann máquinas que se han diseñado para trabajar bien con efectos [1]

La última parte me confunde:

en lugar de ser diseñado para trabajar bien con las lambdas [2]

Son las Lambdas utilizados como símbolos de la programación Funcional?O son euphenisms para la programación funcional?¿Cuál es el verdadero mensaje?

En qué sentido, las partes de la premisa de [1] y [2] son de derecha?¿Cuáles son las premisas ocultas en la respuesta?Puede alguien justificar la premisa original?Cómo hacer la de von-Neumann máquinas y Lambdas realmente funcionan?

Answer 1

No estoy del todo seguro de lo que estás pidiendo, pero a medida que lo leí, que está pidiendo lo que quiere decir con lambdas?

Se refiere a lambda cálculo, que forman gran parte de la base teórica de la programación funcional . Se trata de una notación abstracta para (entre otras cosas) la descripción y el razonamiento acerca de las funciones de orden superior.

Una máquina de Von Neumann es básicamente lo que tenemos. Los programas son ejecutados por instrucciones de manipulación y acceso a una tienda (nuestra memoria RAM). Es decir, todo se hace de forma implícita a través de efectos secundarios. Los datos se leen desde un área en la memoria RAM, procesa un poco, y vuelve a escribir algunos (sí, tal vez) área en la memoria RAM. Sin efectos secundarios, la CPU se limitaría a la manipulación de cualquier dato de basura pasó a ser en sus registros cuando fue encendido.

cálculo lambda no tiene noción de efectos secundarios, por lo que una máquina basada en torno a este principio no tendría la distinción entre "lo que la CPU puede acceder" (nuestros registros, en esencia), y "lo que se puede acceder indirectamente" (nuestra memoria RAM ). Todo en una máquina de este tipo se basa en los principios de funcionamiento, de las funciones de tomar uno o más argumentos, y devolver un nuevo valor, no modificar los existentes. (Y no, no estoy seguro de cómo funcionaría en el hardware ...:))

¿Eso responde a su pregunta?

Answer 2

Aquí es más profundo de lo que I significaba, aunque será interesante ver si otros están de acuerdo o lo que tienen que decir.

Tenga en cuenta cómo funcionan los ordenadores de hoy. Tiene un hardware que tiene enteros y de coma flotante registros, y una amplia gama de memoria de acceso aleatorio, e instrucciones que en su mayoría son de la forma 'basado en la lectura del valor de esta celda de registro / memoria, vaya meter este nuevo valor en este registro /celda'. (Actualización de celdas de memoria tiene todo tipo de implicaciones Potencia cuando se trata de líneas de caché y modelos de coherencia y de la memoria y otras cosas.) Los enteros son 32 o 64 bits, y casi todos los lenguajes de programación superficie de estos tipos de datos que coinciden exactamente con el hardware. Casi todos los tiempo de ejecución funciona con una pequeña pila de llamadas donde los objetos pila asignados son baratos, y una 'Pila' más caro que otros objetos pueden ser creados y destruidos cuando no basado en pila-tiempos de vida son necesarios.

Ahora considere lenguajes de programación funcionales más modernas. Inmutabilidad es la norma; que rara vez 'meter' de memoria con los nuevos valores. (Esto significa que crea más nuevos objetos, lo que significa que asigna más.) Lambdas y continuaciones son la norma; más rara vez tienen tiempos de vida de objetos que corresponden a la pila. (De hecho, algunos tiempos de ejecución de PF no utilizan una pila, en una implementación de CPS la noción de pila y el contador de programa están fuera de lugar.) La recursividad es una construcción de bucle, por lo que al menos necesidad de 'cola' Las llamadas a no consumir la pila de todos modos. Prácticamente todo lo que necesita "montón" asignar, y por supuesto se necesita un liberador de memoria. tipos de datos algebraicos proporcionan datos etiquetada; en teoría, estas etiquetas sólo se requeriría un extra de 2 o 3 bits de datos, pero para que coincida con el tiempo de ejecución, que a menudo necesitan tener una palabra adicional de memoria o más. ... Estoy tipo de serpenteantes, pero las cosas que más a menudo en un lenguaje FP tiendes se corresponda con exactitud a las cosas que Escala peor o están más caro en la arquitectura típica de hardware y tiempo de ejecución de lenguaje básico.

No tiene por qué ser así. Uno puede imaginar un mundo en el que el tiempo de ejecución evita una pila, y hace que el montón / asignación rápida (y no un cuello de botella para aplicaciones multi-hilo). Uno puede imaginar un mundo en el que los tipos enteros interoperables tienen 29 o 60 bits, y el tiempo de ejecución / hardware de utilizar los bits sobrantes adicionales de la palabra por ejemplo, la GC, o etiquetas de tipo algebraicas, o lo que sea. (Creo que algunas implementaciones de PF / tiempos de ejecución hacen algunos de estos trucos.), Etc, etc ... El punto es, si se toma un lenguaje funcional moderna como un hecho, y luego diseñar el tiempo de ejecución / hardware alrededor de ella, se vería muy diferente desde el hardware típico / tiempos de ejecución de hoy.

(no creo que me comuniqué terriblemente, y estoy imprecisa acerca de muchos detalles que no sé exactamente, pero es de esperar que asimilo lo esencial de mi tesis aquí.)