Raros Lenguajes Nuevos: Ela

Sobre el final del año inicio una serie que espero continuar desarrollando durante el incipiente 2011: Raros Lenguajes Nuevos.

La idea es dedicar cada tanto un post a algún nuevo lenguaje que aparezca en el radar, no necesariamente de los esotéricos, si no generalmente aquellos con posibilidades interesantes de ganar adopción o servir de campo experimental en ciertas áreas, aportando ideas que se incorporen en otros lenguajes más populares, como ocurre todo el tiempo en este campo.

 

Ela

En palabras de su creador, Vasily Voronkov: "Ela is a strict dynamically typed impure functional language" (un lenguaje funcional impuro, estricto y dinámicamente tipado). Y está implementado para correr sobre el CLR de .NET ó Mono. Analicemos estas características:

Dinámico se refiere a que los tipos se definen y verifican en tiempo de ejecución, no de compilación, y estricto se refiere a que las asignaciones (por omisión) no se difieren, sino que ocurren en el momento. Los tipos son además fuertes, es decir que no hay conversiones implícitas (no se pueden sumar números y strings, por ejemplo).

Exactamente al revés que en Haskell, que es funcional pero no-escricto (o lazy) por omisión, en Ela esta característica es opcional y debe ser explícita. Por ejemplo:

let x =(&2+2)
let y = x *2//La expresión '2 + 2' se evalúa recién en este momento

El motivo de esto es que Ela está diseñado para ser funcionalmente impuro, también al contrario de Haskell. Esto significa que un programa puede tener efectos colaterales, o más simplemente, mantener estado (usar variables). Los lenguajes funcionales puros solamente admiten constantes y funciones, y no hay estado variable, lo que permite muchas cosas interesantes, pero implica un enorme cambio de mentalidad para cualquier programador que no proviene del mundo de las matemáticas.

Finalmente, la sintaxis general de Ela es relativamente parecida a ML (o el reciente F#), utilizando secuencias, líneas de ejecución y comparación de patrones. Un ejemplo para asustarse (aunque en realidad no es difícil de entender después de algunas reglas básicas, sería:

let filter f x::xs | f x  = x :: filter f xs;
                   |else= filter f xs;
           _ []           =[]

Esto define una función filter que recibe un predicado, es decir una función que evalúa cada elemento en una lista para filtrarla. El uso de esta función para filtrar los elementos mayores que 5 es tan sencillo como:

let filter' = filter (>5)

Como siempre en programación funcional, se trata principalmente de describir el resultado a obtener más que detallar los pasos a seguir para obtenerlo, y Ela sigue bien esta tradición.

¿Qué diferencia a Ela de otros lenguajes?

Además de características funcionales típicas como funciones anónimas (lambdas) y closures, y aplicación parcial.

Sin embargo, Ela toma un decisión interesante respecto de cualquier otro lenguaje (que yo haya visto), y es que toda función debe recibir un único parámetro. No cero ni más de uno. Esto que parece bastante restrictivo se resuelve en forma general haciendo que una función reciba otra, generando encadenamiento, como en:

let res = sum 23// por supuesto, devuelve 5

pero no recibe dos parámetros, sino que sum recibe como entrada 2 y devuelve una función anónima que recibe como parámetro el 3. Veamos la definición de sum:

let sum x y = x + y

Esta es una técnica conocida como currying(que toma su nombre del matemático Haskell Curry, al igual que el lenguaje Haskell que toma la otra mitad). En programación funcional esta es una técnica muy usual para componer funciones, pero no es obligatoria.

A primera vista parece raro, si, pero el hecho de pensar que toda función recibe un único parámetro cambia por completo la sintaxis del lenguaje, ya que no hacen falta más paréntesis ni separadores, y esto tiene un montón de consecuencias interesantes de analizar (y obviamente plantea varios desafíos).

Otra interesante decisión de diseño es que todos los operadores son identificadores únicos, con lo que no hay posibilidad de utilizar un símbolo con diferente semántica en dos contextos. Por ejemplo, el operador "-" (signo menos) significa resta, por lo que el operador unario para indicar un número negativo es "--" (por ejemplo: --2). Raro otra vez, pero hay algunas razones válidas relativas a la capacidad de validación de expresiones en cualquier contexto.

Es importante destacar que aunque el intérprete es totalmente funcional y puede ser embebido en código .NET o Mono, el proyecto está aún en nivel experimental.

Para los interesados, la documentación más completa por ahora es la Wiki en Google Code (en inglés), o este artículo del autor (en ruso).