PpHd (./53) :
Pollux (./52) :
Est-ce que le fait de vérifier si l'argument a bien été évalué est si prohibitif que ça ? Parce que sinon il suffit de supprimer add et d'utiliser add_c à la place, et puis d'appeler eval de façon paresseuse quand on en aura besoin, du coup on peut se débarrasser de tous les _c.
Sauf que une forme non-évaluée ne peut pas franchir la barrière d'une marque déposée (Ex: x =may_cos_c (may_set_ui (2)); may_mark (); x = may_cos (x); est invalide).
Il y a une bonne raison pour ça ? Je vois pas en quoi add_c(x,y) serait fondamentalement différent de la liste {x,y} du point de vue du GC...
Sauf que ca peut nécessiter d'évaluer plusieurs fois la même expression dans 2 branches de codes différentes sauf si je taggue l'expression comme réévalué en tel endroit.
?
Un autre problème de eval est le intmod. Si intmod vaut 2,
may_eval (may_pow_c (may_set_ui_c (17), may_set_ui_c (5))));
ne sera pas pareil que:
may_pow (may_set_ui (17), may_set_ui (5));
car 5 sera évalué lui aussi dans Z/2Z avant l'appel à may_pow.
(Donc oui, tu avais raison).
Ah oui c'est super crade de faire ça... Ca veut dire que finalement tu casses la notion de types explicites dont j'avais parlé. Pourquoi tu ferais pas plutôt une extension pour gérer les types modulo ? (en plus ça serait une bonne occasion de "eat your own dogfood" pour voir si ton système d'extension tient la route, ou si au contraire le fait de rajouter un noeud pour préciser le type est 50x plus lourd que d'avoir une vraie annotation de type sur chaque noeud ; personnellement je penche pour la 2è solution ^^)
may_pow(may_classmod(may_set_ui(17), may_set_ui(2)), may_set_ui(5))
(et euh ton exemple est mal choisi, 17^5 = 17^1 mod 2

mod 3 ça marche par contre)