• [^] # Re: Représentations intermédiaires du compilateur OCaml

    Posté par . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 2.

    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)

    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.

    Certes, x86 permet d'exprimer efficacement les types sommes. Mais la traduction n'est pas simple et demande beaucoup d'effort; ce n'est pas une représentation intermédiaire adaptée pour un compilateur. Au contraire, une représentation intermédiaire pour OCaml essaie de faciliter la représentation efficace de ce qui existe dans le langage, et de manière agréable à produire (si on suppose que le compilateur est bien conçu), donc c'est une indication forte que tous les aspects importants du langage OCaml seront bien couverts par cette représentation.

    Il n'est pas du tout clair que n'importe quel langage permet de représenter les types sommes de façon efficace. En Scheme par exemple, comment coderais-tu quelque chose comme

    type 'a tree =
    | Leaf of 'a
    | Node of 'a tree * 'a tree
    let rec size = function
    | Leaf _ -> 1
    | Node (left, right) -> size left + size right

    Mes idées immédiates pour faire cela sont soit de construire des paires (tag, paramètres), c'est-à-dire une s-exp donc la tête est un symbole 'leaf ou 'node et le nombre d'éléments suivants est en fonction, ce qui donne une représentation moins efficace (OCaml met le nom de constructeur dans le mot de tête aussi utilisé par le GC, alors que là tu paies avec un mot de plus par valeur; et le test d'égalité de symboles est plus lent), ou alors essaie d'utiliser un struct et tester l'identité du type, ce qui donne encore une représentation moins efficace (le nom du type est dans un espace de nom plus grand que les constructeurs fixés ici, et donc va être plus difficile à encoder comme une série de petits entiers consécutifs).