Funciones de orden superior en erlang

Una parte importante de todos los lenguajes de programación funcionales es la capacidad de tomar una función y pasarla como parámetro a otra función. Esto, a su vez, vincula ese parámetro de función a una variable que puede usarse como cualquier otra variable dentro de la función. Una función que puede aceptar otras funciones transportadas de esa manera se denomina función de orden superior. Las funciones de orden superior son un poderoso medio de abstracción y una de las mejores herramientas para dominar Erlang.

Nuevamente, este es un concepto arraigado en las matemáticas, principalmente en el cálculo lambda. No entraré en muchos detalles sobre el cálculo lambda porque a algunas personas les cuesta entenderlo y está un poco fuera de alcance. Sin embargo, lo definiré brevemente como un sistema donde todo es una función, incluso los números. Debido a que todo es una función, las funciones deben aceptar otras funciones como parámetros y pueden operar sobre ellas con aún más funciones.

Muy bien, esto puede resultar un poco extraño, así que comencemos con un ejemplo:

-module(hhfuns).

-compile(export_all).

 

one() -> 1.

two() -> 2.

 

add(X,Y) -> X() + Y().

Ahora abra el shell de Erlang, compile el módulo y comience:

1> c(hhfuns).

{ok, hhfuns}

2> hhfuns:add(one,two).

** exception error: bad function one

in function  hhfuns:add/2

3> hhfuns:add(1,2).

** exception error: bad function 1

in function  hhfuns:add/2

4> hhfuns:add(fun hhfuns:one/0, fun hhfuns:two/0).

3

¿Confuso? No tanto, una vez que sabes cómo funciona (¿no es siempre así?) En el comando 2, los átomos uno y dos se pasan a add/2, que luego usa ambos átomos como nombres de funciones (X() + Y ()). Si los nombres de las funciones se escriben sin una lista de parámetros, esos nombres se interpretan como átomos y los átomos no pueden ser funciones, por lo que la llamada falla. Esta es la razón por la que la expresión 3 también falla: los valores 1 y 2 tampoco se pueden llamar funciones, ¡y lo que necesitamos son funciones!

Es por eso que se debe agregar una nueva notación al lenguaje para permitirle pasar funciones desde fuera de un módulo. Esto es lo divertido que es Módulo: Función/Arity: le dice a la VM que use esa función específica y luego la vincule a una variable.

Entonces, ¿cuáles son las ventajas de utilizar funciones de esa manera? Bueno, quizá sea necesario un pequeño ejemplo para entenderlo. Agregaremos algunas funciones a hhfuns que funcionan de forma recursiva en una lista para sumar o restar uno de cada número entero de una lista:

increment([]) -> [];

increment([H|T]) -> [H+1|increment(T)].

 

decrement([]) -> [];

decrement([H|T]) -> [H-1|decrement(T)].

¿Ves cuán similares son estas funciones? Básicamente hacen lo mismo: recorren una lista, aplican una función en cada elemento (+ o -) y luego se llaman a sí mismos nuevamente. Casi nada cambia en ese código: solo la función aplicada y la llamada recursiva son diferentes. El núcleo de una llamada recursiva en una lista como esa es siempre el mismo. Resumiremos todas las partes similares en una sola función (mapa/2) que tomará otra función como argumento:

map(_, []) -> [];

map(F, [H|T]) -> [F(H)|map(F,T)].

 

incr(X) -> X + 1.

decr(X) -> X - 1.

Que luego se puede probar en el shell:

1> c(hhfuns).

{ok, hhfuns}

2> L = [1,2,3,4,5].

[1,2,3,4,5]

3> hhfuns:increment(L).

[2,3,4,5,6]

4> hhfuns:decrement(L).

[0,1,2,3,4]

5> hhfuns:map(fun hhfuns:incr/1, L).

[2,3,4,5,6]

6> hhfuns:map(fun hhfuns:decr/1, L).

[0,1,2,3,4]

Aquí los resultados son los mismos, ¡pero acabas de crear una abstracción muy inteligente! Cada vez que quieras aplicar una función a cada elemento de una lista, solo tienes que llamar a map/2 con tu función como parámetro. Sin embargo, es un poco molesto tener que poner cada función que queremos pasar como parámetro a map/2 en un módulo, nombrarla, exportarla, luego compilarla, etc. De hecho, es claramente poco práctico. Lo que necesitamos son funciones que puedan declararse sobre la marcha...