Contrairement à scheme, les specs du langage de disent pas que l'optimisation doit être faite. Il ne faut pas compter dessus. C'est comme en C d'ailleurs... J'ai déjà vu des programmes C qui plantaient en mode debug seulement parce que la TCO n'était pas faite.
En pratique, GHC la fait souvent, même si la fonction n'est pas tail récursive. (comme la factorielle définie ci dessus)
Il est bon de noter que l'optimisation n'est pas toujours une bonne chose, en effet elle empêche toute mémoization ou réutilisation de calculs.
Ceci dit, il y a des cas trivials ou l'optimisation doit être faite, par exemple l'appel récursif à main pour faire boucler un programme. Si elle n'est pas faite, ça plante.
[^] # Re: Tail-call optimization de la factorielle ?
Posté par Zylabon . En réponse à la dépêche Sortie du livre « Parallel and Concurrent Programming in Haskell ». Évalué à 5.
Contrairement à scheme, les specs du langage de disent pas que l'optimisation doit être faite. Il ne faut pas compter dessus. C'est comme en C d'ailleurs... J'ai déjà vu des programmes C qui plantaient en mode debug seulement parce que la TCO n'était pas faite.
En pratique, GHC la fait souvent, même si la fonction n'est pas tail récursive. (comme la factorielle définie ci dessus)
Il est bon de noter que l'optimisation n'est pas toujours une bonne chose, en effet elle empêche toute mémoization ou réutilisation de calculs.
Ceci dit, il y a des cas trivials ou l'optimisation doit être faite, par exemple l'appel récursif à main pour faire boucler un programme. Si elle n'est pas faite, ça plante.
Please do not feed the trolls