Pollux (./54) :
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...

La raison est que les fils de x qui appartient à un espace N ne peuvent jamais appartenir à un espace N+1. Seulement <= N.

Pollux (./54) :
Ah oui c'est super crade de faire ça...

Tu n'as que ce mot à la bouche

Pollux (./54) :
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 ^^)

C'est prévu (Et j'en ai déjà fait des extensions - les lists par exemple).
En fait, je sais pas trop comment gérer la notion de RootOf, et je me demande si mod ne serait pas une solution convenable pour gérer les extensions algébriques.
En gros, on aura les transformations suivantes:
mod(x,2)+3*mod(y,2) -> mod(x+y,2)
mod(f12),2) -> mod(f(12),2)
mod(x^3+x,x^2+1,x) -> mod(-x+,x^2+1,x)
mod(mod(x^3+x,x^2+1,x),3) -> mod(mod(2*x+1,x^2+1,x),3)
Et faudra surcharger les appels à degree, expand, gcd, ...

Pollux (./54) :
(et euh ton exemple est mal choisi, 17^5 = 17^1 mod 2 mod 3 ça marche par contre)

Oups...