Citer : Posté le 18/12/2020 08:08 | #

---

Well to start, you should plan out your language first.
- How will you separate code into blocks for control flow?
- What types of variables will there be?
- Will there be functions/subroutines, and if so how will they be defined/called?
When you have a good idea of what your language will look like, it will be much easier to design a parser for it. There are many good resources online for all this

---

Citer : Posté le 18/12/2020 08:56 | #

---

Il y a pas mal de choses que tu vois bien : oui l'outil qui « crée » le langage c'est le compilateur ou l'interpréteur, l'analyse syntaxique joue un rôle important, et on veut gérer les questions d'orthographe/ponctuation/etc (on dit lexicales).

Compilé vs interprété n'est pas deux types de langages, juste deux façons de coder un langage. Il existe des interpréteurs Basic et des compilateurs Basic. Il existe un interpréteur Python (canonique) et aussi un compilateur Python (Cython). C'est juste un choix à faire (et en fait beaucoup de code est partagé entre les deux).

Dans un langage de programmation, il est important de séparer deux concepts :
• La syntaxe c'est le format dans lequel on écrit le programme. Les mots-clés, la ponctuation, les accolades, Unicode, les blocs imbriqués, etc.
• La sémantique c'est la signification du programme. Variables locales et globales, fonctions, itération non bornée, récursion, etc.

Quand tu commences à jouer avec les outils, pouvoir maîtriser et influencer la syntaxe est super fun et valorisant. Mais au bout de quelques temps, on finit par réaliser que la sémantique est beaucoup plus profonde et définit plus fondamentalement le langage. En général donc on s'attarde plus sur la sémantique. Mais n'hésite pas à jouer avec la syntaxe autant que tu veux.

En pratique, un compilateur ou un interpréteur effectue plusieurs transformations successives du programme pour partir du fichier texte et arriver jusqu'à un résultat exécutable, soit à la volée (interpréteur) soit dans un autre langage (compilateur). Au début, le programme est juste un paquet de texte :

print("Hello, " + get_current_user());

On commence par faire une analyse lexicale qui groupe les caractères en mots. C'est ici qu'on gère la présence d'espaces (ou plus précisément qu'on les ignore la plupart du temps), et à partir de là on ne se soucie plus jamais jamais du texte du programme. Il ne reste plus qu'un flot de mots appelés « tokens » :

NAME(print) LPAR STR("Hello, ") PLUS NAME(get_current_user) LPAR RPAR RPAR SEMICOL

Ensuite on fait une analyse syntaxique pour grouper les tokens en « phrases ». C'est ici qu'on gère l'imbrication avec les parenthèses/accolades/etc. À partir de là on ne se soucie plus jamais de quel mot est écrit après quel autre, il ne reste plus qu'un objet structuré appelé « arbre de syntaxe » ou AST.

CALL(VAR(print), PLUS(STR("Hello, "), CALL(VAR(get_current_user))))

Puis vient la première partie « intéressante » qui est l'analyse sémantique. C'est ici que tu identifies toutes les variables locales et globales, que tu détermines le type des expressions et des opérateurs. Par exemple si get_current_user() renvoie un entier, tu peux décider que le + est invalide ou décider de convertir automatiquement en texte. Dans le deuxième cas l'AST peut devenir :

CALL(VAR(print), STR_CONCAT(STR("Hello, "), INT2STR(CALL(VAR(get_current_user)))))

Si tu programmes un interpréteur, tu peux parcourir récursivement l'arbre obtenu par l'analyse sémantique et exécuter le programme immédiatement. Si tu programmes un compilateur, il faut ensuite régénérer ton programme dans le langage cible. Par exemple si tu compiles vers du C, ça peut donner :

char *t1 = str_from_int(get_current_user());
char *t2 = str_concat("Hello, ", t1);
mylang_print(t2);
free(t2);
free(t1);

Donc voilà en gros les étapes à prendre. Pour information, un compilateur moderne ne génère pas directement du C comme ça, après l'analyse sémantique il génère une représentation intermédiaire qui est généralement du code à trois adresses, une sorte de langage universel. Ensuite il fait plein d'optimisations sur cette représentation intermédiaire, et enfin il produit du code cible (de l'assembleur, du C, etc).

Je pense que dans ton cas ce qui est important c'est de faire un truc propre avant de faire un truc complet. L'analyse lexicale c'est chiant à faire à la main : non pas que ce soit fondamentalement compliqué, mais c'est compliqué à faire efficacement. L'analyse syntaxique c'est chiant à faire à la main aussi sauf si la grammaire est LL(1), et là c'est de la vraie théorie compliquée. Les deux peuvent s'automatiser, il y a des outils (des générateurs de lexers et générateurs de parsers) auxquels tu dis à quoi ressemble le langage et qui génèrent les deux premières étapes pour toi. Je te conseille de générer le lexer et de faire un parser LL(1) comme Shadow15510 dans "Compylateur".

Voilà donc une roadmap :
1. Définir la syntaxe et la sémantique de ton langage. Je te conseille de commencer avec un truc super facile genre juste des calculs arithmétiques avec deux types de valeurs (entiers et flottants) et les conversions automatiques, ça te donnera les bonnes bases.
2. Écrire une grammaire pour ton langage. Tu peux lire des choses sur les grammaires formelles. L'article est très formel mais tu peux lire la section avec des exemples pour te faire une idée.
3. Écrire ou générer un lexer et un parser.
4. Faire un peu d'analyse sémantique juste pour vérifier que le programme a du sens.
5. Interpréter l'AST en sortie de l'analyse sémantique.
6. Étendre le langage, faire une étape de génération de code, ou ce que tu veux en fait.

Voilà voilà.

---