Backend Haskell
On supporte haskell à prologin cette année ! C'est toujours formidable pour l'association de gérer un langage de plus, mais j'aurais préféré qu'ils choisissent d'ajouter un langage qui est déjà géré dans Metalang, ou au pire, un langage plus proche du C...
Pour ce backend, je suis parti de l'AST fonctionnel, évidement. J'ai galéré pour les effets dans les déclarations et dans les applications. La gestion de l'indentation a elle aussi posé pas mal de soucis. J'ai du définir deux nouvelles passes : une pour renomer les variables qu'on écrasait avant, et une autre pour détecter les effets de bords. Pour le moment, on est super conservatif pour les effets de bords : quand on appelle une fonction, elle fait forcément des effets.
Les records m'ont cassé l'espace de nommage aussi : en Haskell, un champ de record est simplement une fonction (un accesseur) et donc, je me suis retrouvé avec deux choses qui en metalang sont dans deux espaces de nommages séparés, alors qu'en haskell c'est le meme. J'ai commencé par renommer les champs de records et les noms des types (ça tombait bien puisque j'avais un TODO la dessus parce-qu'on pouvait y mettre des mots clés de certains langages) et ensuite, j'ai eu le soucis de collision avec des variables locales. J'ai simplement choisi de préfixer mes records.
Le code généré pue vraiment pour plusieurs raisons : on utilise des tableaux mutables, les structures sont avec des références, et l'AST fonctionnel n'est pas très proche de ce que l'humain a écrit. Du coup, le code produit a vraiment une sale tete de code généré et j'ignore ce qui arrivera si un candidat tombe dessus... Il est peu probable que ce code serve à prologin.
Ce backend est là plus pour le défis qu'autre chose. Il est assez inutilisable en l'état et je doute qu'il puisse etre utilisable un jour à prologin.