Archive for December 23, 2009

Haskell, C# y Currying

Aunque el concepto de “Currying” no es algo extraño para los lenguajes funcionales (y por lo tanto bastante conocido entre usuarios de este tipo de lenguajes). No es sólo una palabra extraña sino un concepto quizás desconocido para muchos usuarios de lenguajes imperativos como C#.

Currying (llamado así en nombre de Haskell Curry) no es más que el efecto de tomar de forma individual parámetro por parámetro y procesar cada parámetro por separado en su propia función, esto lo logramos tranformando el método o función en cuestión por uno que tome uno de los parámetros y una función para luego retornar otra función. Por ejemplo, tomemos el hecho de una simple suma:

sum       :: (Int, Int) -> Int
sum (x, y) = x + y

En este caso indicamos una función llamada sum que toma dos parámetros de tipo Int y retorna un parámetro de tipo Int. Dado que las funciones son ciudadanos de primer orden en los lenguajes funcionales, podemos transformarla y definir una función que tome como uno de sus parámetros una función y retorne otra función

sum'     :: Int -> Int -> Int
sum' x y = x + y

En este caso, creamos la función sum’ que toma un parámetro tipo Int y retorna otra función que toma un parámetro tipo Int y retorna un Int. Si, ya se que a simple vista esto puede parecer extraño, pero regresemos a ver un par de puntos claves: Currying involucra evaluar uno a uno los parámetros de una función pudiendo retornar otra función en su lugar.

Bien, regresemos a la Tierra y veamos como podemos transformar este tipo de cosas en una forma más "C#". Aprovechando los métodos lambda en C# (otra adición netamente funcional) podemos describir algo como esto:

public static void Main()
{
    Func<int, int, int> sum =
        (x, y) => x + y;

    int result = sum(1,2);

    Console.WriteLine(result);
}

Pero que les parecería si cambiamos "un poco" la definición de la función sum:

public static void Main()
{
    Func<int, Func<int, int>> sum =
        x => y => x + y;

    int result = sum(1)(2);
    Console.WriteLine(result);
}

Ahora sum en vez de tomar dos enteros como parámetro y retornar un entero, ahora toma un entero retorna una función (que toma un entero y retorna otro entero) como parámetros. De esta manera sum(1) retornará otra función que luego toma el parámetro 2 y retorna 3, wow…

El concepto de currying es práctico, permite definir funciones complejas a partir de funciones mucho más simples, aunque la definición en C# parece compleja, en realidad permite definir una función a partir de simplemente un parámetro (el cual convenientemente puede permanecer dentro de la función como si fuera una constante).

public static void Main()
{
    Func<int, Func<int, int>> ntimes =
        x => y => x * y;

    var twice = ntimes(2);
    var three = ntimes(3);

    Console.WriteLine(twice(4));
    Console.WriteLine(three(4));
}

Es interesante todo lo que podríamos lograr con solamente un poco de imaginación. :)

C# y el caracter Wildcard de Haskell

Escuchando al Dr. Meijer en su serie Functional Programming with Haskell, me topé con algo interesante: el caracter wildcard de Haskell. El "wildcard” (_) en Haskell es prácticamente lo mismo que el caracter wildcard (*) en nuestros sistemas operativos, evalúa o implica cualquier “otra cosa”. Por ejemplo:

(&&)         :: Bool -> Bool -> Bool
True && True = True
_ && _       = False

Tiene una interpretación sumamente sencilla: “Dada una función llamada &&, que toma un Bool y retorna una función que toma un Bool y retorna un Bool siendo sus parámetros True y True retornará True, de cualquier otra manera, retornará False”. A simple vista pensaremos que en lenguajes de “diario” no existen conceptos como el de “wildcard”, pero como lo dice luego el Dr. Meijer, en C# si tenemos el concepto de wildcard, claro, con nuestros amigos los Generics (otro concepto tomado de lenguajes funcionales y que data de muchos años atrás :P ).

En C# el guión bajo es un nombre aceptado de una variable, así que podemos utilizarlo como caracter de wildcard (a lo Haskell), imaginemos la declaración desiguiente tipo genérico:

public interface IRepository<T> {
    T GetById(int id);
}

Bien, que tal si lo nombramos algo así:

public interface IRepository<_> {
    _ GetById(int id);
}

Debo admitir que en mi caso lo veo algo extraño para los tipos de retorno… Que tal si usamos un wildcard para aquellos tipos que "debemos" definir pero que no "vamos" a utilizar.

// Siendo esta la declaración de un evento
runtime.RuntimeStarted += (sender, e) => Console.WriteLine(e.InstanceId);

// De igual manera, sender es un Object el cual no utilizamos
runtime.RuntimeStarted += (_, e) => Console.WriteLine(e.InstanceId);

Si, ya se que más de algún usuario de VB.NET me comentará que en VB9 no es necesario declarar en los eventos aquellos parámetros que no utilizaremos, pero esa es harina de otro costal.

Al parecer si hay un par de cosas que un usuario de C# puede aprender de Haskell… Saludos!