Parfait !

La table de transitions est une représentation du graphe. Il existe des algorithmes pour passer de l'un à l'autre. C'est un peu comme coder un graphe sous forme de listes d'adjacences, sauf qu'on y représente les transitions plutôt que les états.

La liste des actions permet d'automatiser des choses. Prenons le cas des valeurs supérieures à zéro : elle permette d'arriver à un point précis dans le switch (de la méthode consume), donc ce sont des liens vers des points du programme (le switch peut encore redirigé sur des méthodes si besoin bien sûr), des sortes de goto dynamiques .
Si la valeur de l'action est inférieure à zéro, alors ce sont des actions spéciales (repérées par le paquetage et sur lesquelle l'utilisateur ne peut pas intervenir … pour l'instant). Ainsi, -1 permet de remplir le tampon 0, et -2 permet de le vider. Mais -3 remplit le tampon 1 etc. En fait : -x remplit le tampon (x - 1) / 2 et -x - 1 vide le tampon (x - 2) / 2. Un bête décalage quoi.
C'est comme ça que je remplis les tampons pour les clés et les valeurs dans mon exemple, ça se fait automatiquement.

Maintenant Hoa_Compiler supporte les sous-automates. C'est beaucoup plus puissant et plus rapide. Je vais recoder un exemple demain dans la journée, c'était prévu .

L'idée est que tu as tes sous-automates liés par des transitions-epsilon, et qu'un état doit d'abord rentrer et sortir de son sous-automate lié avant de continuer. Ça permet d'avoir des boucles assez complexes ou de mieux gérer les parenthèses, accolades etc., bref : tout ce qui aurait besoin de piles.

Surtout qu'à la déclaration, ça ne change pas grand chose. Au lieu d'avoir un tableau pour la table de transitions, on aura un tableau de tableau. Pareil pour les tokens, skip, actions etc.