La question se pose aussi dans l'autre sens: pourquoi choisir Lisp plutôt que OCaml ?
Quand je dis lisp, c'est un lisp ou un scheme. Par exemple chicken scheme. Les avantages sont :
La syntaxe est spécifiée pour le scheme : si le code n'utilise pas d'extensions c'est même très basique
Le compilateur est fait pour être intégré dans une application (dans le cas de chicken scheme), ce qui n'est pas le cas d'ocaml
Malfunction pourrait être une collections de macros qui génèrent le code adéquat pour les fonctions « haut niveau » comme le pattern matching
Après, les points négatifs sont bien sûr
À priori pas de types sommes (mais dans malfunction non plus si, puisque Lambda n'en a pas ... ?)
Pas d'interaction avec l'écosystème ocaml
On peut payer le coût du runtime, être confronté aux limitations du compilateur, du garbage collector ... mais c'est pareil avec ocaml (à moins qu'il ne soit techniquement meilleur)
Je ne suis pas certain de tout maîtriser, mais il me semble que Lambda ne possède pas
de système de type : l'argument de l'interaction typée avec les autres programmes tombe
de type somme : donc c'est malfunction qui fait cette traduction, et elle pourrait aussi bien se faire avec un lisp/scheme
[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par Aluminium95 . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 1.
Quand je dis lisp, c'est un lisp ou un scheme. Par exemple chicken scheme. Les avantages sont :
Après, les points négatifs sont bien sûr
Je ne suis pas certain de tout maîtriser, mais il me semble que Lambda ne possède pas
Mais je peux me tromper.