La représentation interne Lambda (qui est bien celle que vise Malfunction) n'est effectivement pas spécifiée et peut changer d'une version du compilateur à l'autre. Par contre le langage d'entrée de Malfunction est spécifiée, et plus simple que Lambda; Malfunction va produire du code pour une version spécifique du compilateur OCaml, mais peut s'adapter pour suivre les changements de représentation du Lambda.
La question est donc : pourquoi utiliser le compilateur OCaml ? Les performances sont-elles vraiment meilleures qu'un lisp compilé ?
Je pense que les backends/runtimes des bonnes implémentations Lisp (SBCL par exemple) et de OCaml sont relativement comparables en terme de qualité aujourd'hui. La question se pose aussi dans l'autre sens: pourquoi choisir Lisp plutôt que OCaml ?
La gestion des types algébriques, avec une représentation des valeurs efficaces, peut être un argument en faveur de OCaml—à ma connaissance les Lisp n'ont pas de représentation natives pour ce genre de valeurs, qui sont très utilisées par les adopteurs potentiels (Idris, Agda, Eff, Links, etc.).
(À l'inverse certains Scheme ont des continuations efficaces, ce qui peut être important pour certains langages, mais pas les Lisps à ma connaissance.)
Un autre argument est l'interopérabilité : partager une représentation interne et le runtime ça permet aussi une communication inter-langage à moindre coûts (comme c'est facile entre les langages qui tournent sur la JVM ou le CLR), et ces langages peuvent être plus intéressés par le fait d'interagir avec un langage typé, qui permet de donner des garanties partielles de sûreté au niveau du lien entre les fragments de programmes écrits dans différents langages.
[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par gasche . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 3. Dernière modification le 26 juin 2016 à 15:55.
La représentation interne Lambda (qui est bien celle que vise Malfunction) n'est effectivement pas spécifiée et peut changer d'une version du compilateur à l'autre. Par contre le langage d'entrée de Malfunction est spécifiée, et plus simple que Lambda; Malfunction va produire du code pour une version spécifique du compilateur OCaml, mais peut s'adapter pour suivre les changements de représentation du Lambda.
Je pense que les backends/runtimes des bonnes implémentations Lisp (SBCL par exemple) et de OCaml sont relativement comparables en terme de qualité aujourd'hui. La question se pose aussi dans l'autre sens: pourquoi choisir Lisp plutôt que OCaml ?
La gestion des types algébriques, avec une représentation des valeurs efficaces, peut être un argument en faveur de OCaml—à ma connaissance les Lisp n'ont pas de représentation natives pour ce genre de valeurs, qui sont très utilisées par les adopteurs potentiels (Idris, Agda, Eff, Links, etc.).
(À l'inverse certains Scheme ont des continuations efficaces, ce qui peut être important pour certains langages, mais pas les Lisps à ma connaissance.)
Un autre argument est l'interopérabilité : partager une représentation interne et le runtime ça permet aussi une communication inter-langage à moindre coûts (comme c'est facile entre les langages qui tournent sur la JVM ou le CLR), et ces langages peuvent être plus intéressés par le fait d'interagir avec un langage typé, qui permet de donner des garanties partielles de sûreté au niveau du lien entre les fragments de programmes écrits dans différents langages.