BookeldOr
:

Pollux :
37) ben le compilateur pourrait automatiquement générer des "templates" dans ces cas-là (i.e. une fonction acceptant un (float tree) pourrait avoir une version (really_a_float tree) et une version (int_disguised_as_float tree))

ok, donc comme je disais ce n'est pas de la compilation mais de la macro-génération, (avec le cas échéant de la propagation de code jusqu'à la compilation pour afficher des messages clairs,...)

Ben oui, c'est de la macro-génération si tu veux, mais je vois pas pkoi ça serait pas de la compilation Et le typage c'est pas de la compilation ?

Là par contre même avec l'architecture un peu merdique de Caml ça devrait pouvoir se faire, puisque Caml doit bien pouvoir discerner dynamiquement entre les deux ? (enfin effectivement ça demanderait peut-être de recoder proprement la lib standard avec des classes)

ocaml n'a aucun système de propagation de types, donc aucune vérification dynamique à l'exécution n'est possible (ce qui fait en partie son efficacité d'ailleurs!)

Euh si, c'est possible, sinon comment crois-tu que les fonctions de comparaison ou d'affichage d'un objet générique font pour savoir quoi faire ? Par contre effectivement il n'y a aucune vérification dynamique dans les fonctions autres que ces fonctions "systèmes" parce que tout a été vérifié statiquement, mais ça n'a rien à voir avec ce que je disais ^^

sinon, pour transformer une chaine en char et vice-versa, ça doit etre faisable avec des Obj.magic

Oui mais non Obj.magic, ça contourne juste le typage (comme les casts du C), ça change pas la structure de mémoire derrière, et ça me paraît assez évident que les char et les string n'ont pas du tout la même structure interne en caml...