Représenter une architecture, dans CAKE©, n'est pas une métaphore : c'est la fonction exacte de l'arbre syntaxique. Tout programme C%, quelle que soit sa taille, devient la même structure : un projet, qui contient une classe racine, qui contient une méthode principale, dont le corps est un bloc de nœuds typés. Cette régularité est ce qui permet ensuite de transformer, comparer et certifier.
Le CXML est la forme écrite de cet arbre. Ce n'est pas un format que l'on invente à côté du code : c'est ce que l'analyseur produit lui-même, balise par balise, à partir du source.
| Opcode C% | Famille | Nœud d'arbre | Balise CXML | Exécuté |
|---|---|---|---|---|
=: | DECL | déclaration | <declaration nom type valeur/> | oui |
=:! | DECL | déclaration constante | <declaration type="val:var"/> | oui |
:= :+ | DECL | affectation | <affectation cible valeur/> | oui |
=$ =$? =$! | FLOW | si / sinon si / sinon | <si><alors>…<sinon> | oui |
$= | FLOW | tant-que | <tant-que condition> | oui |
|>, Cake.… | IORC, CALL | appel | <appel methode args/> | oui |
$$ $$: | FLOW | pour / pour-chaque | <pour> <pour-chaque> | oui |
!{ … !} !~ | ERRH | essayer / capturer / final | <essai> <attraper> | oui |
<@: | fonction | méthode de la classe racine | <methode nom retour> | oui |
Cake.error | CALL | appel | message sur le canal de diagnostic, l'exécution continue | partiel |
La dernière colonne est le fruit des vérifications de ce tome. Les boucles $$ et $$:, les blocs d'erreur et les fonctions ne fonctionnaient pas dans l'éditeur avant les correctifs de septembre 2026 ; le chapitre 10 raconte comment ces défauts ont été trouvés en écrivant ce tome.
L'exemple suivant contient une boucle imbriquée dans une condition. Dépliez le CXML : l'imbrication du source se retrouve exactement dans celle des balises, et chaque :+ i=1 est devenu une affectation explicite i + 1. L'arbre ne garde aucun raccourci d'écriture ; il garde le sens.
t09c04-a.cake=: niveau=3%
=: capteurs=0%
=$ (niveau>0) {
=: i=0%
$= (i<niveau) {
:+ capteurs=4%
:+ i=1%
}
}
|> "Capteurs actifs : " + Cake.toString(capteurs)%
Capteurs actifs : 12
<projet nom="t09c04-a" package="com.unibool.script" type="Library">
<classe nom="Root" visibilite="Public">
<methode nom="main" retour="void" visibilite="Public">
<bloc>
<declaration nom="niveau" type="var" valeur="3"/>
<declaration nom="capteurs" type="var" valeur="0"/>
<si condition="niveau>0">
<alors>
<bloc>
<declaration nom="i" type="var" valeur="0"/>
<tant-que condition="i<niveau">
<bloc>
<affectation cible="capteurs" valeur="capteurs + 4"/>
<affectation cible="i" valeur="i + 1"/>
</bloc>
</tant-que>
</bloc>
</alors>
</si>
<appel methode="println" args=""Capteurs actifs : " + Cake.toString(capteurs)"/>
</bloc>
</methode>
</classe>
</projet=: déclarations · =$ flux · $= flux · :+ déclarations · |> entrées/sorties · bibliothèque : Cake.toStringcf04ab0299b492b2 (reproductible : cake hash t09c04-a.cake)Le tome 13 montrait des balises CXML comme <Runtime>, <Accepts> ou <Connect>. Ces balises décrivent une intention de conception ; l'analyseur actuel ne les reconnaît pas. Elles sont désormais signalées comme notation conceptuelle, et seules les balises produites par l'analyseur, comme celles de ce chapitre, sont présentées comme du CXML.
Le CXML n'est pas un dessin de l'architecture : c'est l'architecture elle-même, écrite par l'analyseur. Ce qui n'a pas de balise produite n'existe pas encore dans le moteur.
Le chapitre suivant se sert de cet arbre pour ce qu'il a de plus précieux : exprimer la même intention dans d'autres langages.