D'une part, le code est incorrect si je commence à construire des arbres de paires; en OCaml 'a peut être instancié par (int * int) par exemple. D'autre part l'encodage ne passe pas à l'échelle si j'ai plusieurs constructeurs, par exemple un constructeur pour les noeuds noirs et un pour les rouges dans un arbre rouge-noir; ou alors deux types de feuilles différentes, etc.
Je ne dis pas que c'est dur (ci-dessus je proposais des encodages qui sont relativement agréables à utiliser si le langage a du pattern-matching comme racket/match par exemple), mais je pense que trouver une représentation générique n'est pas aussi simple et risque de pêcher en performances par rapport à un runtime (et surtout un choix de représentation des valeurs) qui gère ça en dur.
[^] # 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 27 juin 2016 à 21:51.
D'une part, le code est incorrect si je commence à construire des arbres de paires; en OCaml
'apeut être instancié par(int * int)par exemple. D'autre part l'encodage ne passe pas à l'échelle si j'ai plusieurs constructeurs, par exemple un constructeur pour les noeuds noirs et un pour les rouges dans un arbre rouge-noir; ou alors deux types de feuilles différentes, etc.Je ne dis pas que c'est dur (ci-dessus je proposais des encodages qui sont relativement agréables à utiliser si le langage a du pattern-matching comme racket/match par exemple), mais je pense que trouver une représentation générique n'est pas aussi simple et risque de pêcher en performances par rapport à un runtime (et surtout un choix de représentation des valeurs) qui gère ça en dur.