En la última Elixir Conf EU 2022, la keynote fue a cargo de José Valim y dedicó gran parte de su tiempo a explicar por qué Elixir no tendrá tipos. No como el resto de lenguajes, ¿quieres saber por qué?
Para mi asombro y supongo que también el de José Valim, a la pregunta que formuló de ¿a cuántos de vosotros os gustaría ver tipos de datos en Elixir? la gran y amplia mayoría de la sala levantó la mano. Todos quería poder utilizar tipos de datos en sus códigos o al menos esa lectura saqué yo.
La siguiente noticia que José preparaba era un trabajo de investigación que realizará junto a Guillaume Duboc y el profesor Giuseppe Castagna para proveer de Tipos de Conjuntos Teóricos (set-theoretic types en inglés) a Elixir.
Tras la presentación un grupo de personas comenzaron a hacerle preguntas sobre los tipos y terminó formando un corro en el hall de entrada a las conferencias donde intentó responder a todas las preguntas que no se pudieron formular tras su presentación por la falta de tiempo.
Además de explicar el proyecto durante su presentación, compartió un hilo en el que comenta el objeto de estudio.
En principio y viendo el código no se diferencia mucho de lo que ya podemos ver en un @spec normal de Elixir, es decir, el ejemplo de código que expone es el siguiente:
# Unions and singleton types
File.read(path()) :: {:ok, binary()} | {:error, atom()}
En este primer trozo de código podemos ver la definición de una función dentro de un módulo (File) y una especificación de tipos. Es similar a agregar sobre la función:
@spec read(path()) :: {:ok, binary()} | {:error, atom()}No obstante, la primera forma sugiere una mezcla de la definición dentro del código, lo que implicaría una comprobación más cercana y precisa por parte del compilador. El segundo trozo de código viene a ilustrar una forma de indicar cómo implementar tipos de forma explícita en Elixir:
# Intersections
def example(arg) when is_integer(arg) do
# interesting code...
end
def example(arg) when is_atom(arg) do
# interesting code...
end
Aquí estamos indicando que el arg pasado como parámetro en la función example/1 puede tomar valores tanto de números enteros como de átomos. Sería el conjunto de tipos de datos soportado por la función.
José nos comenta en el tuit que están mapeando todas las características funcionales de Elixir para la teoría de tipos de conjuntos teóricos y cuando esté terminado se enfocarán en agregar inferencia básica de tipos para Elixir. Esto les permitirá obtener retroalimentación (en rendimiento, mensajes de error, ...) sin ningún cambio en la base de código existente.
Tras echar un vistazo a las posibilidades hasta el momento me doy perfecta cuenta de que incluso con este sistema de declaración de tipos, lo único que parece se quiere mejorar es el compilador pero sin necesidad de cambiar la forma de escribir el código en Elixir, es decir, da la sensación de que como mucho habrá partes donde se deba especificar algún que otro tipo para no confundir al compilador o facilitar su acción de detección de tipos.
Conclusiones
Tal y como dice José, no esperéis cambios pronto. El mensaje importante es que están explorando el espacio del problema y todo podría resultar en la imposibilidad de obtener un sistema de tipos finalmente. Hay mucho trabajo e investigación que deben realizar aún y podría no ser satisfactoria al fin.
Nos prometen más información y noticias sobre el avance del proyecto y el agradecimiento para las empresas que se han embarcado con ellos en este esfuerzo: el organismo de investigación francés CNRS y Remote; y las empresas patrocinadoras: Supabase, Fresha y Dashbit.
Si quieres saber más sobre los tipos de datos puedes echar un vistazo a Programming with union, intersection, and negation types de Giuseppe Castagna.
¿Qué te parece que Elixir pueda tener un sistema de inferencia de tipos? ¿Te gustaría que tuviese algún sistema de definición de tipos? ¡Déjanos tu comentario!
