S01E22 — 19-08-2024.
EX_FINITE_STATE_MACHINA.
jour 22.
Qu’est-ce que j’adore implémenter une machine à état. Je trouve que c’est plus ou moins simple à conceptualiser et permet de contrôler chaque cas méticuleusement bien. Certes, en fonction du problème et de sa compléxité, on peut se retrouver avec beaucoup de cas à gérer. Mais c’est la même pour d’autres approches. Je n’ose même pas m’imaginer une implémentation sous forme de Regex, ça doit être ultra horrible à débugger. Aucun plaisir… Dans le cas, de l’écriture d’un Tokenizer, tu vas vite te rendre compte que c’est un algorithme adapté et très rapide surtout si tu n’as pas besoin de reconsommer le caractère précédant.
Je suis convaincu que c’est l’approche que je dois suivre. En effet, dans mon langage de programmation les changements de mode se font au caractère près. C-à-d qu’un contrôle fin est nécessaire. Par exemple, une fois sur le symbole ::=, je suis obligé d’intervertir le mode tu Tokenizer dans le mode template, car tous les caractères suivants seront des caractères de la famille XML. Puis je rebascule en mode normal pour analyser le reste des caractères qui eux correspondent au mode initial. Et c’est là que la machine à états prends tout son sens.
En étudiant la spécification HTML5 du W3C, tu te rends compte de la difficulté à parser du HTML. D’abord, il faut connaître qu’est qu’un élément. D’arpès la spécification, il y a cinq types d’éléments:
- Void (Vide)
- Raw Text (Texte brut)
- RCDATA (Texte brut)
- Foreign (Étrangers)
- Normal (Normal)
Du coup, j’apprends que la balise <svg> est considérée comme un élément étranger comme la balise <math>. Alors que les balises <script> et <style> sont eux considérer comme étant de la famille Texte Brut. Comme leur contenu n’est pas en corrélation avec du HTML, il y a une distinction claire qui est faite. Ce qui veut dire qu’au niveau du Tokenizer, on ne doit pas prendre en compte le contenu enfant de ces balises sans pour autant ne pas le récupérer.
Du coup, pour mon cas, je vais surement devoir procéder autrement. Ils ont dû procéder de la sorte pour le CSS et le JavaScript qui n’ont rien à voir avec le HTML. Mais dans la situation d’un langage moderne, c-à-d que le contenu qui sera dans la balise <script> sera du langage zo en mode Program. Du contenu qui serait susceptible de contenir le symbole </ ce qui est interdit dans les éléments de texte brut.
Par contre, pour la balise <style>, c’est intéressant de suivre la spécification. Je dois encore réfléchir là-dessus. Tonnerre de Brest ! J’ai l’impression que je passe mes journées et mes nuits à réfléchir à tous les cas possibles. Je pourrais récolter le contenu CSS ou d’un préprocesseur et utiliser la caisse Lightning CSS pour transformer le texte en un arbre que je pourrai manipuler. D’ailleurs, j’hésite encore entre aller vers du WASM ou utiliser egui. Si je me tourne vers le WASM directement, je devrais implémenter une sur-couche pour la partie native, tandis que si j’ai une sur-couche egui, la caisse s’occupera de la partie WASM et de la partie native. T’imagines le kif d’avoir un langage pour viser plusieurs plateformes cibles avec un langage similaire au HTML pour le templating. Sty-lé !
Bon j’y retourne, car je n’ai encore rien branlé aujourd’hui, toutes mes approches ne sont pas concluantes.