Oui, donc il faut encore plus une syntaxe spécifiée, c'est à dire, avec une spécification. Parce que bon, dépendre d'un truc qui peut casser à tout moment je trouve que c'est pas super. Ou alors il faut que ocaml puisse garantir une certaine stabilité de cette représentation intermédiaire, ce qui apparement n'est pas à l'ordre du jour.
C'est en fait le point clef d'utiliser un scheme plutôt qu'une représentation qui de l'avis même de l'auteur, n'aurait jamais du être exposée en dehors du compilateur.
Encore une fois, la syntaxe importe peu. Malfunction permet d'utiliser le back-end d'OCaml (donc tout la compilation d'un bytecode bas niveau vers du code natif) comme c'est le cas avec LLVM-IR. LLVM-IR a aussi une syntaxe et on peut très bien soit produire à partir d'une librairie du code LLVM-IR et le piper vers le compilateur LLVM (et c'est le cas avec Kaleidoscope) ou utiliser une librairie qui fait cette glue entre représentation intermédiaire et code natif (comme c'est le cas avec le compiler-libs d'OCaml).
Il est en effet dit que le bytecode Lambda d'OCaml n'a pas l'ambition d'être stable. Maintenant, je pense que Malfunction peut se doter de cette caractéristique en étant lui même une abstraction de Lambda (et donc de faire la glue nécessaire entre les différentes versions de Lambda).
Le point est surtout d'offrir un outil qui permet de produire du code natif spécialisé pour des langages fonctionnels. La comparaison, selon l'objectif de Malfunction, avec Scheme ne se porterait, en l'état pour l'instant, que sur les performances - on peut pas vraiment parler encore de stabilité et de compatibilité vu le numéro de version du projet. Un propos, et c'est ce que souligne Gasche, c'est une comparaison des performances entre le runtime OCaml et le runtime des différentes implémentations de Scheme.
De plus, j'ai l'impression que du confonds la syntaxe de malfunction et la syntaxe de Lambda. Qui sont apparemment deux langages différents,
Encore une fois, si la différence est purement syntaxique (en incluant les sucres syntaxiques qui peuvent faire la glue entre les différentes versions de Lambda), elle n'est pas importante.
Ce qui veut dire que même une fois que ton langage devient « mûr » tu veux continuer à utiliser cette architecture ? Même si de ton propre avis
si pour cela il faut piper dans un fichier texte au milieu, je ne vois pas vraiment le soucis
Ce qui (pour moi) sous-entends que c'est une phase « alpha », prototype, enfin, quelque chose de pas propre.
C'est ce que fait un compilation de manière général, piper une représentation intermédiaire d'une passe à une autre et c'est l'objectif même de LLVM-IR ou de Malfunction: passer d'un dialecte à un autre. Si techniquement ensuite, on utilise un pipe nommé ou whatever, ça reste un détail technique qui je pense peut être très facilement remplacé (et qui n'a que peut d'importance et qui, surtout, ne concerne en rien la qualité propre du dit langage).
Et quand on voudra le faire proprement, voilà ce qu'il va se passer :
manipuler directement la compilation (mais encore une fois elle n'est pas stable)
Ah, bah, on repose sur un truc instable, génial.
Justement, Malfunction peut s'assurer d'une API stable en étant lui même une abstraction d'une représentation intermédiaire (le Lambda) qui, heureusement, évolue - tout comme LLVM-IR évolue et a aussi des casse de compatibilité mais qui offre des librairie permettant de produire cette représentation intermédiaire qui garantissent un minimum de stabilité (et c'est le cas pour les librairies disponibles en OCaml et en C++).
Je veux bien te croire sur parole (étant donné qu'il n'existe pas de spécification du langage), mais cet argument est quand même bien foireux, je te le refais
ASM x86 a bien une représentation des valeurs qui permet de manipuler les types sommes (puisque c'est la représentation du compilateur OCaml, qui en a)
Hophophop, voilà ! Bon, j'ai retiré « intermédiaire » et changé le nom ... Soit ce que tu dis est qu'il est possible de le faire simplement, ce qui est le cas dans à peu près n'importe quel langage (même x86) soit tu dis qu'il existe une syntaxe spéciale, et alors l'argument n'a aucune valeur.
C'est là où on voit que tu as une méconnaissance de l'objectif réel de Malfunction. Bien entendu que tu peux faire toi même un back-end vers ASM x86 ayant une représentation optimisé des types sommes mais la véritable question est: est ce que tu veux réellement produire toi même de l'ASM x86 ? et quid des autres ASM ? Malfunction réponds à cette question en te proposant un langage intermédiaire qui produit du Lambda pouvant être directement manipuler par le back-end d'OCaml et ainsi compiler vers du natif (et pas uniquement du x86) en proposant un runtime optimisé pour les langages fonctionnels (comme c'est le cas pour Idris).
C'est comme LLVM-IR mais qui reste un langage intermédiaire bas niveau et pas forcément optimisé pour les langages fonctionnels de base - il peut bien sûr être complété par un runtime optimisé pour un langage fonctionnel (comme c'est le cas pour Haskell - mais ça demande des manipulations qui ont d'ailleurs eu lieu en plein dans la spécification de LLVM-IR). Le point est surtout de proposer un runtime avec un garbage-collector pensé pour les langages fonctionnels (et pour le coup, l'intégration d'un GC fait maison dans LLVM-IR est une tâche difficile).
C'est minime, c'est juste que bon, tu n'as pas à construire :
Un lexer
Un parser
Un programme qui va compiler un AST vers un autre langage
Bah euh, c'est justement le point. Malfunction offre juste un langage intermédiaire. Après c'est à toi de faire le langage haut niveau par dessus Malfunction qui reste une représentation intermédiaire pour un back-end spécifique aux langages fonctionnels. Et pour preuve, l'auteur a réussi à utiliser Malfunction dans Idris - il a rien changé Idris (même si il dénote que certaines constructions du langage ne sont pas disponible avec Malfunction - mais je pense que c'est surtout une question de temps et de travail) mais il a changé le back-end avec, selon ses dires, un gain de performance non négligeable.
Donc oui, tu devras toujours faire un lexer/parser/passe vers Malfunction comme c'est le cas aussi pour LLVM-IR. Mais c'est l'intérêt même de Malfunction. Donc je vois pas trop ce que tu essayes de dénoter ici.
On ne peut pas le faire en utilisant un programme C intermédiaire ? Ça revient presque au même (parce que la glue et l'analyse de type tu la feras quand même). C'est plus complexe techniquement, certes.
"C'est plus complexe techniquement, certes." et c'est bien la raison de Malfunction.
[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par Dinosaure (site web personnel) . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 1.
Encore une fois, la syntaxe importe peu. Malfunction permet d'utiliser le back-end d'OCaml (donc tout la compilation d'un bytecode bas niveau vers du code natif) comme c'est le cas avec LLVM-IR. LLVM-IR a aussi une syntaxe et on peut très bien soit produire à partir d'une librairie du code LLVM-IR et le piper vers le compilateur LLVM (et c'est le cas avec Kaleidoscope) ou utiliser une librairie qui fait cette glue entre représentation intermédiaire et code natif (comme c'est le cas avec le
compiler-libsd'OCaml).Il est en effet dit que le bytecode Lambda d'OCaml n'a pas l'ambition d'être stable. Maintenant, je pense que Malfunction peut se doter de cette caractéristique en étant lui même une abstraction de Lambda (et donc de faire la glue nécessaire entre les différentes versions de Lambda).
Le point est surtout d'offrir un outil qui permet de produire du code natif spécialisé pour des langages fonctionnels. La comparaison, selon l'objectif de Malfunction, avec Scheme ne se porterait, en l'état pour l'instant, que sur les performances - on peut pas vraiment parler encore de stabilité et de compatibilité vu le numéro de version du projet. Un propos, et c'est ce que souligne Gasche, c'est une comparaison des performances entre le runtime OCaml et le runtime des différentes implémentations de Scheme.
Encore une fois, si la différence est purement syntaxique (en incluant les sucres syntaxiques qui peuvent faire la glue entre les différentes versions de Lambda), elle n'est pas importante.
C'est ce que fait un compilation de manière général, piper une représentation intermédiaire d'une passe à une autre et c'est l'objectif même de LLVM-IR ou de Malfunction: passer d'un dialecte à un autre. Si techniquement ensuite, on utilise un pipe nommé ou whatever, ça reste un détail technique qui je pense peut être très facilement remplacé (et qui n'a que peut d'importance et qui, surtout, ne concerne en rien la qualité propre du dit langage).
Justement, Malfunction peut s'assurer d'une API stable en étant lui même une abstraction d'une représentation intermédiaire (le Lambda) qui, heureusement, évolue - tout comme LLVM-IR évolue et a aussi des casse de compatibilité mais qui offre des librairie permettant de produire cette représentation intermédiaire qui garantissent un minimum de stabilité (et c'est le cas pour les librairies disponibles en OCaml et en C++).
C'est là où on voit que tu as une méconnaissance de l'objectif réel de Malfunction. Bien entendu que tu peux faire toi même un back-end vers ASM x86 ayant une représentation optimisé des types sommes mais la véritable question est: est ce que tu veux réellement produire toi même de l'ASM x86 ? et quid des autres ASM ? Malfunction réponds à cette question en te proposant un langage intermédiaire qui produit du Lambda pouvant être directement manipuler par le back-end d'OCaml et ainsi compiler vers du natif (et pas uniquement du x86) en proposant un runtime optimisé pour les langages fonctionnels (comme c'est le cas pour Idris).
C'est comme LLVM-IR mais qui reste un langage intermédiaire bas niveau et pas forcément optimisé pour les langages fonctionnels de base - il peut bien sûr être complété par un runtime optimisé pour un langage fonctionnel (comme c'est le cas pour Haskell - mais ça demande des manipulations qui ont d'ailleurs eu lieu en plein dans la spécification de LLVM-IR). Le point est surtout de proposer un runtime avec un garbage-collector pensé pour les langages fonctionnels (et pour le coup, l'intégration d'un GC fait maison dans LLVM-IR est une tâche difficile).
Bah euh, c'est justement le point. Malfunction offre juste un langage intermédiaire. Après c'est à toi de faire le langage haut niveau par dessus Malfunction qui reste une représentation intermédiaire pour un back-end spécifique aux langages fonctionnels. Et pour preuve, l'auteur a réussi à utiliser Malfunction dans Idris - il a rien changé Idris (même si il dénote que certaines constructions du langage ne sont pas disponible avec Malfunction - mais je pense que c'est surtout une question de temps et de travail) mais il a changé le back-end avec, selon ses dires, un gain de performance non négligeable.
Donc oui, tu devras toujours faire un lexer/parser/passe vers Malfunction comme c'est le cas aussi pour LLVM-IR. Mais c'est l'intérêt même de Malfunction. Donc je vois pas trop ce que tu essayes de dénoter ici.
"C'est plus complexe techniquement, certes." et c'est bien la raison de Malfunction.