Je n'ai pas testé encore flambda, mais sauf surprise il inline juste la fonction, mais sans changer la sémantique d'évaluation, ce qui veut dire que les arguments sont évalués avant. Par exemple : let () = iff true (print_int 4) (print_int 2) va afficher 42.
Effectivement j'ai parlé trop vite, flambda fait de même pour ne pas changer la sémantique d'évaluation, même si les deux compilateurs (le classique et le flambda) comprennent que l'expression finira dans la première branche. Ils inlinent et suppriment même le test, mais évaluent quand même les expressions à cause des effets de bord qu'elles contiennent. En revanche en l'absence d'effet de bord, c'est compilé comme pour les macros en Common Lisp.
Après que les macros offrent toutes les possibilités que tu décris, je ne le nie pas : cela permet de gérer deux stratégies différentes de beta-réduction sur les \lambda-termes. À l'exécution en commençant par les paramètres sur les fonctions, ou à la compilation sur le corps de la macro. Là où pour l'instant OCaml ne dispose que de la première stratégie, même si l'inlining a fortement à voir avec la seconde. Ce sont deux approches du \lambda-calcul qu'il est intéressant de comparer, même si je ne lâcherai pour rien au monde la puissance du système de types d'OCaml (statique et très grande expressivité). Le système de \lambda-calcul typé le plus puissant étant Coq comme je l'avais expliqué ici : un programme Coq qui compile est garanti sans bug, comme le compilateur CompCert (le seul à ma connaissance) développé par Xavier Leroy, le BDFL OCaml.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: C'est bien dommage
Posté par kantien . En réponse au journal C++17 est sur les rails. Évalué à 1.
Effectivement j'ai parlé trop vite, flambda fait de même pour ne pas changer la sémantique d'évaluation, même si les deux compilateurs (le classique et le flambda) comprennent que l'expression finira dans la première branche. Ils inlinent et suppriment même le test, mais évaluent quand même les expressions à cause des effets de bord qu'elles contiennent. En revanche en l'absence d'effet de bord, c'est compilé comme pour les macros en Common Lisp.
Après que les macros offrent toutes les possibilités que tu décris, je ne le nie pas : cela permet de gérer deux stratégies différentes de beta-réduction sur les \lambda-termes. À l'exécution en commençant par les paramètres sur les fonctions, ou à la compilation sur le corps de la macro. Là où pour l'instant OCaml ne dispose que de la première stratégie, même si l'inlining a fortement à voir avec la seconde. Ce sont deux approches du \lambda-calcul qu'il est intéressant de comparer, même si je ne lâcherai pour rien au monde la puissance du système de types d'OCaml (statique et très grande expressivité). Le système de \lambda-calcul typé le plus puissant étant Coq comme je l'avais expliqué ici : un programme Coq qui compile est garanti sans bug, comme le compilateur CompCert (le seul à ma connaissance) développé par Xavier Leroy, le BDFL OCaml.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.