Dans un langage comme Java ça ne marche pas parce que les expressions e1 et e2 seraient évaluées systématiquement avant d'être passées en paramètre à la fonction iff.
C'est le cas aussi en OCaml, c'est un langage strict, contrairement à Haskell qui est paresseux, par exemple. Le iff est ici juste une fonction. En OCaml la seule façon d'étendre la syntaxe et de contrôler l'évaluation, et créer une nouvelle structure de contrôle, est d'utiliser camlp4/5 ou maintenant les ppx. Je suppose qu'avec la directive lazy pour évaluer paresseusement on pourrait faire un iff à peu près raisonnable, mais pas totalement naturel à utiliser.
OCaml, du fait de son typage statique poussé et des garanties qui vont avec se heurte à pas mal de difficultés pour faire du méta-programming. Utiliser les ppx c'est clairement moins facile pour un programmeur OCaml lambda (perso, il me faudrait potasser l'AST un moment) que faire une macro en Common Lisp (tout programmeur connait l'AST). Quels que soient les progrès, faire du méta-programming ne sera probablement jamais aussi facile qu'en Lisp.
L'approche c'est plutôt : le méta-programming n'est pas quelque chose dont a vraiment besoin un programmeur quotidiennement, donc on se contente d'une approche moins accessible et plus limitée, mais compatible avec le système de types pointu d'OCaml. Du coup, on ne fait pas une extension dès qu'une petite factorisation potentielle se présente. Par exemple, des fois avec un match sur un type somme avec beaucoup de cas, on s'aperçoit qu'on fait syntaxiquement plusieurs fois une chose quasiment identique, et parfois pas moyen de raccourcir, mais ça n'arrive pas très souvent : il semble improbable que ça représente une proportion significative du code. Personnellement, je trouve le compromis plutôt intéressant en pratique : un langage avec suffisamment de syntaxe au départ pour traiter les cas courants n'a pas tous les jours besoin d'une extension, même s'il arrive toujours un moment où sans cela on écrit du code plus verbeux.
[^] # Re: C'est bien dommage
Posté par anaseto . En réponse au journal C++17 est sur les rails. Évalué à 2.
C'est le cas aussi en OCaml, c'est un langage strict, contrairement à Haskell qui est paresseux, par exemple. Le
iffest ici juste une fonction. En OCaml la seule façon d'étendre la syntaxe et de contrôler l'évaluation, et créer une nouvelle structure de contrôle, est d'utiliser camlp4/5 ou maintenant les ppx. Je suppose qu'avec la directivelazypour évaluer paresseusement on pourrait faire uniffà peu près raisonnable, mais pas totalement naturel à utiliser.OCaml, du fait de son typage statique poussé et des garanties qui vont avec se heurte à pas mal de difficultés pour faire du méta-programming. Utiliser les ppx c'est clairement moins facile pour un programmeur OCaml lambda (perso, il me faudrait potasser l'AST un moment) que faire une macro en Common Lisp (tout programmeur connait l'AST). Quels que soient les progrès, faire du méta-programming ne sera probablement jamais aussi facile qu'en Lisp.
L'approche c'est plutôt : le méta-programming n'est pas quelque chose dont a vraiment besoin un programmeur quotidiennement, donc on se contente d'une approche moins accessible et plus limitée, mais compatible avec le système de types pointu d'OCaml. Du coup, on ne fait pas une extension dès qu'une petite factorisation potentielle se présente. Par exemple, des fois avec un match sur un type somme avec beaucoup de cas, on s'aperçoit qu'on fait syntaxiquement plusieurs fois une chose quasiment identique, et parfois pas moyen de raccourcir, mais ça n'arrive pas très souvent : il semble improbable que ça représente une proportion significative du code. Personnellement, je trouve le compromis plutôt intéressant en pratique : un langage avec suffisamment de syntaxe au départ pour traiter les cas courants n'a pas tous les jours besoin d'une extension, même s'il arrive toujours un moment où sans cela on écrit du code plus verbeux.