scala - ingles - perezoso meme

¿Qué tan puro y perezoso puede ser Scala?

Question

Esta es solo una de esas preguntas de "Me preguntaba ...".

Scala tiene estructuras de datos inmutables y (opcional) valores perezosos, etc.

¿Qué tan cerca puede estar un programa Scala de uno que sea completamente puro (en un sentido de programación funcional) y completamente perezoso (o, como señala Ingo, puede ser lo suficientemente no estricto)? ¿Qué valores son inevitablemente mutables y qué evaluación inevitablemente codiciosa?

Answer 1

Scala puede ser tan puro y perezoso como quieras, pero a) el compilador no te mantendrá honesto con respecto a la pureza yb) tomará un poco de trabajo extra para hacerlo perezoso. No hay nada demasiado profundo en esto; incluso puede escribir código Java puro y perezoso si realmente lo desea (vea here si se atreve; lograr la pereza en Java requiere cantidades increíbles de clases internas anónimas anidadas).

Pureza

Mientras que Haskell rastrea las impurezas a través del sistema de tipos, Scala ha optado por no ir por ese camino, y es difícil abordar ese tipo de cosas cuando no se ha hecho un objetivo desde el principio (y también cuando la interoperabilidad con un lenguaje completamente impuro. Como Java es un objetivo importante del lenguaje).

Dicho esto, algunos creen que es posible y que vale la pena hacer el esfuerzo de documentar los efectos en el sistema de tipos de Scala. Pero creo que la pureza en Scala se trata mejor como una cuestión de autodisciplina, y debe ser perpetuamente escéptico acerca de la supuesta pureza del código de terceros.

pereza

Haskell es perezoso por defecto, pero se puede hacer más estricto con algunas anotaciones en su código ... Scala es lo contrario: estricto por defecto, pero con la palabra clave y los parámetros de nombre perezosos puede hacerlo tan perezoso como desee.

Answer 2

Siéntete libre de mantener las cosas inmutables. Por otro lado, no hay un seguimiento de los efectos secundarios, por lo que no puede imponerlo ni verificarlo.

En cuanto a lo que no es estricto, este es el trato ... Primero, si eliges ser completamente no estricto, estarás abandonando todas las clases de Scala. Incluso Scalaz no es no estricto en su mayor parte. Si está dispuesto a construir todo usted mismo, puede hacer que sus métodos no sean estrictos y que sus valores sean perezosos.

A continuación, me pregunto si los parámetros implícitos pueden ser no estrictos o no, o cuáles serían las consecuencias de hacerlos no estrictos. No veo un problema, pero podría estar equivocado.

Pero, lo más problemático de todo, los parámetros de función son estrictos, y también lo son los parámetros de cierre.

Entonces, si bien es teóricamente posible ir totalmente no estricto, será increíblemente inconveniente.

Answer 3

Con respecto a la pereza , actualmente, pasar un parámetro a un método es por defecto estricto:

def square(a: Int) = a * a

pero utiliza parámetros de llamada por nombre:

def square(a: =>Int) = a * a

pero esto no es perezoso en el sentido de que calcula el valor solo una vez cuando es necesario:

scala> square({println("calculating");5})
calculating
calculating
res0: Int = 25

Se ha trabajado para agregar parámetros de método perezoso , pero aún no se ha integrado (la siguiente declaración debería imprimir "calculating" desde arriba solo una vez):

def square(lazy a: Int) = a * a

Esta es una pieza que falta, aunque se podría simular con un valor perezoso local:

def square(ap: =>Int) = {
  lazy val a = ap
  a * a
}

Respecto a la mutabilidad : no hay nada que le impida escribir estructuras de datos inmutables y evitar la mutación. Puedes hacer esto en Java o C también. De hecho, algunas estructuras de datos inmutables se basan en la primitiva perezosa para lograr mejores límites de complejidad, pero la primitiva perezosa también se puede simular en otros idiomas, a costa de una sintaxis adicional y una plantilla.

Siempre puede escribir estructuras de datos inmutables, cálculos perezosos y programas completamente puros en Scala. El problema es que el modelo de programación de Scala también permite escribir programas no puros, por lo que el verificador de tipos no siempre puede inferir algunas propiedades del programa (como la pureza) que podría inferir dado que el modelo de programación era más restrictivo.

Por ejemplo, en un lenguaje con expresiones puras, la a * a en la definición de llamada por nombre anterior ( a: =>Int ) podría optimizarse para evaluar a sola vez, independientemente de la semántica de llamada por nombre. Si el lenguaje permite efectos secundarios, dicha optimización no siempre es aplicable.