usar una tutorial sumar son que las fórmula función funciones funcion avanzadas anidadas anidada functional-programming nested side-effects

functional-programming - tutorial - usar funciones anidadas en una fórmula



Funciones anidadas: ¿uso inapropiado de efectos secundarios? (3)

Estoy aprendiendo programación funcional, y he tratado de resolver un par de problemas en un estilo funcional. Una cosa que experimenté, mientras dividía mi problema en funciones, era que parecía tener dos opciones: usar varias funciones dispares con listas de parámetros similares, o usar funciones anidadas que, como cierres, pueden referirse simplemente a enlaces en la función primaria.

Aunque terminé yendo con el segundo enfoque, porque hacía las llamadas de función más pequeñas y parecía "sentirse" mejor, desde mi lectura parece que me puede estar faltando uno de los puntos principales de la programación funcional, en el sentido de que esto parece "lado -eficacia "? Ahora bien, estas funciones anidadas no pueden modificar los enlaces externos, ya que el lenguaje que estaba usando evita eso, pero si observas cada función interna individual, no puedes decir "dados los mismos parámetros, esta función arrojará los mismos resultados" porque usan las variables del alcance principal ... ¿estoy en lo cierto?

¿Cuál es la forma deseable de proceder?

¡Gracias!


Considere el siguiente fragmento (artificial) de Haskell:

putLines :: [String] -> IO () putLines lines = putStr string where string = concat lines

string es una constante llamada enlazada localmente. Pero, ¿no es también una función que no toma argumentos que cierra lines y, por lo tanto, es referencialmente intransparente? (¡En Haskell, las constantes y las funciones nulary son indistinguibles!) ¿Consideraría que el código anterior es "de efecto secundario" o no funcional debido a esto?


La programación funcional no es todo o nada. Si anidar las funciones tiene más sentido, seguiría con ese enfoque. Sin embargo, si realmente desea que las funciones internas sean puramente funcionales, pase explícitamente todos los parámetros necesarios.

Aquí hay un pequeño ejemplo en Scheme:

(define (foo a) (define (bar b) (+ a b)) ; getting a from outer scope, not purely functional (bar 3)) (define (foo a) (define (bar a b) (+ a b)) ; getting a from function parameters, purely functional (bar a 3)) (define (bar a b) ; since this is purely functional, we can remove it from its (+ a b)) ; environment and it still works (define (foo a) (bar a 3))

Personalmente, me inclino por el primer enfoque, pero cualquiera funcionará igual de bien.


Las funciones de anidamiento son una forma excelente de dividir el trabajo en muchas funciones. No es realmente "de efecto secundario"; si ayuda, piense en las variables capturadas como parámetros implícitos.

Un ejemplo donde las funciones anidadas son útiles es reemplazar los bucles. Los parámetros de la función anidada pueden actuar como variables de inducción que acumulan valores. Un simple ejemplo:

let factorial n = let rec facHelper p n = if n = 1 then p else facHelper (p*n) (n-1) in facHelper 1 n

En este caso, no tendría sentido declarar una función como facHelper globalmente, ya que los usuarios no deberían tener que preocuparse por el parámetro p .

Tenga en cuenta, sin embargo, que puede ser difícil probar las funciones anidadas individualmente, ya que no pueden ser referidas fuera de su padre.