Support de la circularité dans les listes et les espaces de noms

Jusqu'à présent, les révisions expérimentales précédentes fuyaient la circularité.

Ainsi, il n'était pas possible d'ajouter une liste dans elle-même. Des routines comme la recherche d'éléments, la duplication et la comparaison d'éléments dans une liste circulaire était infinie (du moins jusqu'à ce que la pile soit remplie).

Et si nous utilisions la circularité. Ceci serait vu comme un changement de stratégie (comme dans le cas d'autres situations), il s'agirait d'adopter une stratégie optimiste.

Cette stratégie serait optimiste non dans le sens où on considérerait qu'il n'y aura pas du tout de circularité, mais bien que celle-ci puisse être possible et de mettre en oeuvre les moyens de contourner le problème.

Par exemple, si on teste l'équipollence entre deux listes circulaires, comme faire pour sortir de la boucle dès lors que tous les éléments ont été testé au moins une fois.

Déjà au départ, on sait que pour tester une équipollence, il faut que le test précédent soit terminé dans le même processus. On peut donc implémenter 2 listes au niveau du processus (Interpreter) que l'on rempli lorsqu'on commence à tester des éléments. Tant qu'on en teste de nouveau sans avoir terminé les tests précédent, on place les éléments conteneurs dans une liste (une par partie testée - dans (=? a b), il faut une liste pour les éléments de a et une autre liste pour les éléments de b).

Lors qu'un élément se trouve plus de 2 fois dans chaque liste (respectivement pour a et b), cela signifie qu'on a fait le tour, on peut passer au suivant s'il y en a un et restaurer la pile.

Ceci est un exemple, mais la méthode Node.createClone() est déjà failsafe pour la circularité. Il suffit d'appliquer cette stratégie partout.