fonction de type int -> int -> int sous sa forme optimisée
1) le type "optimisé" est une conséquence de l'utilisation des GADT et ne présume en rien de l'efficacité de l'implémentation
2) de fait, tu as encore besoin d'un interprêteur, eval : 'a repr -> 'a.
Ne te méprends pas sur mon commentaire, je trouve cette technique intéressante, de part justement du trade-off facilité d'implémentation vs performance inhérent à tout interpréteur. J'aime bien aussi utiliser les modules; j'en profite pour te conseiller la lecture du papier "module mania" qui explique comment faire un interpréteur "extensible" sans gadt et sans first-class module.
Metaocaml joue dans une autre catégorie en permettant 1) de spécialiser/optimiser au niveau natif (vs au niveau de l'interpréteur) 2) d'avoir du multistage et de la fiabilité (ce que tu perdrais en transformant ton interpréteur en générateur de code).
Mon instinct me dit que tu devrais pouvoir utiliser metaocaml pour implémenter ton "eval" de manière efficace tout en conservant ton architecture d'extension par modules. Malheureusement il n'y a pas de gadt (pas encore ?) dans MO donc tu devras t'en passer, idem au niveau des foncteurs ça risque d'être un peu plus compliqué; néanmoins ça serait intéressant que tu t'y essayes lors de ton expérimentation avec MO.
[^] # Re: Tagless final un chemin vers MetaOCaml en bibliothèque ?
Posté par benja . En réponse au journal Découvrir MetaOCaml dans son navigateur. Évalué à 2.
1) le type "optimisé" est une conséquence de l'utilisation des GADT et ne présume en rien de l'efficacité de l'implémentation
2) de fait, tu as encore besoin d'un interprêteur, eval : 'a repr -> 'a.
Ne te méprends pas sur mon commentaire, je trouve cette technique intéressante, de part justement du trade-off facilité d'implémentation vs performance inhérent à tout interpréteur. J'aime bien aussi utiliser les modules; j'en profite pour te conseiller la lecture du papier "module mania" qui explique comment faire un interpréteur "extensible" sans gadt et sans first-class module.
Metaocaml joue dans une autre catégorie en permettant 1) de spécialiser/optimiser au niveau natif (vs au niveau de l'interpréteur) 2) d'avoir du multistage et de la fiabilité (ce que tu perdrais en transformant ton interpréteur en générateur de code).
Mon instinct me dit que tu devrais pouvoir utiliser metaocaml pour implémenter ton "eval" de manière efficace tout en conservant ton architecture d'extension par modules. Malheureusement il n'y a pas de gadt (pas encore ?) dans MO donc tu devras t'en passer, idem au niveau des foncteurs ça risque d'être un peu plus compliqué; néanmoins ça serait intéressant que tu t'y essayes lors de ton expérimentation avec MO.