Je n'arrive pas à trouver des informations fiables sur les performances de Chicken Scheme par rapport à OCaml. C'est un des Scheme efficaces, et il y a une communauté derrière (cf. la relativement large couverture de bibliothèque (eggs) disponibles), mais très peu d'information trouvables en ligne sur les performance en pratique.
Par ailleurs pour servir de représentation intermédiaire il faut que les utilisateurs puissent écrire du code bas niveau, où des informations de typage partielles sont connues et exploitées. Il me semblait que Chicken se restreignait à R5RS. Quel est le support dans le langage pour dire qu'une donnée est un entier de 32 bits, ou ne peut pas être un pointeur, pour manipuler des flottants non boxés, etc. ? Ou alors tu as en tête l'usage d'une représentation intermédiaire utilisée par Chicken (comme le bytecode Guile par exemple), mais alors laquelle ?
La syntaxe est spécifiée pour le scheme : si le code n'utilise pas d'extensions c'est même très basique
La syntaxe n'a pas grand chose à voir avec le but de Malfunction. C'est un langage intermédiaire, pas un langage de surface pour les utilisateurs. Du moment que la syntaxe est non-ambiguë, clairement définie et facile à produire et à lire, ça pourrait être du XML ça n'aurait aucune importance.
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
Beuh, encore une fois le but c'est d'obtenir facilement un compilateur décent pour un langage expérimental à moindre coût, si pour cela il faut piper dans un fichier texte au milieu je ne vois pas vraiment le soucis. Par ailleurs le compilateur OCaml expose une API pour manipuler directement la compilation (mais encore une fois elle n'est pas stable) si c'est vraiment important.
Malfunction pourrait être une collections de macros qui génèrent le code adéquat pour les fonctions « haut niveau » comme le pattern matching
Je ne vois pas vraiment l'intérêt.
À priori pas de types sommes (mais dans malfunction non plus si, puisque Lambda n'en a pas ... ?)
Lambda a bien une représentation des valeurs qui permet de manipuler les types sommes (puisque c'est la représentation intermédiaire du compilateur OCaml, qui en a). Par contre il n'y a pas de pattern-matching complexe au niveau de Lambda (seulement des switches sur les tags ou des entiers), puisque le pattern-matching est compilé en amont, après le typage.
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
Imagine que j'ai un programme OCaml qui veut appeler une fonction Links (ou Eff ou Idris) ou l'inverse. Je peux vérifier que les types sont à peu près cohérents (les deux langages n'ont pas les mêmes types mais il y a sous-ensemble commun qui garantissent à peu près les mêmes comportements), compiler les deux vers Lambda et les lier ensemble. Pas besoin que Lambda lui-même soit typé, il faut seulement que les stratégies de compilation choisies pour ces types communs soient compatibles (ou qu'on sache insèrer un peu de code glue entre les deux).
Par exemple ça peut permettre d'échanger facilement des données de grande taille (par exemple un gros terme de preuve généré par Idris) sans copie/traduction, parce qu'en partageant le backend et le runtime tu as la même représentation des deux côtés.
[^] # 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.
Je n'arrive pas à trouver des informations fiables sur les performances de Chicken Scheme par rapport à OCaml. C'est un des Scheme efficaces, et il y a une communauté derrière (cf. la relativement large couverture de bibliothèque (eggs) disponibles), mais très peu d'information trouvables en ligne sur les performance en pratique.
Par ailleurs pour servir de représentation intermédiaire il faut que les utilisateurs puissent écrire du code bas niveau, où des informations de typage partielles sont connues et exploitées. Il me semblait que Chicken se restreignait à R5RS. Quel est le support dans le langage pour dire qu'une donnée est un entier de 32 bits, ou ne peut pas être un pointeur, pour manipuler des flottants non boxés, etc. ? Ou alors tu as en tête l'usage d'une représentation intermédiaire utilisée par Chicken (comme le bytecode Guile par exemple), mais alors laquelle ?
La syntaxe n'a pas grand chose à voir avec le but de Malfunction. C'est un langage intermédiaire, pas un langage de surface pour les utilisateurs. Du moment que la syntaxe est non-ambiguë, clairement définie et facile à produire et à lire, ça pourrait être du XML ça n'aurait aucune importance.
Beuh, encore une fois le but c'est d'obtenir facilement un compilateur décent pour un langage expérimental à moindre coût, si pour cela il faut piper dans un fichier texte au milieu je ne vois pas vraiment le soucis. Par ailleurs le compilateur OCaml expose une API pour manipuler directement la compilation (mais encore une fois elle n'est pas stable) si c'est vraiment important.
Je ne vois pas vraiment l'intérêt.
Lambda a bien une représentation des valeurs qui permet de manipuler les types sommes (puisque c'est la représentation intermédiaire du compilateur OCaml, qui en a). Par contre il n'y a pas de pattern-matching complexe au niveau de Lambda (seulement des switches sur les tags ou des entiers), puisque le pattern-matching est compilé en amont, après le typage.
Imagine que j'ai un programme OCaml qui veut appeler une fonction Links (ou Eff ou Idris) ou l'inverse. Je peux vérifier que les types sont à peu près cohérents (les deux langages n'ont pas les mêmes types mais il y a sous-ensemble commun qui garantissent à peu près les mêmes comportements), compiler les deux vers Lambda et les lier ensemble. Pas besoin que Lambda lui-même soit typé, il faut seulement que les stratégies de compilation choisies pour ces types communs soient compatibles (ou qu'on sache insèrer un peu de code glue entre les deux).
Par exemple ça peut permettre d'échanger facilement des données de grande taille (par exemple un gros terme de preuve généré par Idris) sans copie/traduction, parce qu'en partageant le backend et le runtime tu as la même représentation des deux côtés.