• [^] # Re: C'est bien dommage

    Posté par . En réponse au journal C++17 est sur les rails. Évalué à 2. Dernière modification le 21 mars 2016 à 18:42.

    Par exemple le compilateur actuel remplace systématiquement les appels à ma fonction iff par if b then e1 else e2 (comme si c'était une macro en Common Lisp)

    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. Le if fait à partir de cond en Common Lisp sera lui un vrai if (même si comme l'a remarqué ylsul en vrai c'est l'inverse, et if n'est pas une vraie macro, plutôt une macro built-in on pourrait dire).

    le pattern matching qui est une version généralisée de ta macro cond

    Mais en Lisp tu peux, uniquement à l'aide de macros, définir un pattern matching à la OCaml (il y a plusieurs packages qui font ça dans différents dialectes). En fait, c'est même possible de créer un système de types statique uniquement à l'aide de macros (comme c'est fait dans une extension de Racket). Ou créer un langage de documentation comme scribble pour Racket, qui est en fait un programme Racket valide (pas un langage spécial à part avec des commentaires ou quelque chose comme ça, je trouve ça plutôt sympa). Bref, les possibilités offertes par les macros Lisp sont assez difficiles à égaler, et OCaml va difficilement gagner sur ce terrain. Après, c'est loin d'être un critère ultime, la plupart des cas où les macros permettent une solution élégante ont des alternatives tout à fait acceptables, parfois intégrées au langage de façon ad hoc ou à l'aide d'un outil externe (souvent plus léger).