rédiger un parser : méthodologie

Bonjour,

je souhaite rédiger un parser simple, et je voudrais avoir les retours de gens qui ont l'expérience de ce genre de chose.

Plutôt qu'un tuto sur flex/bison, j'aimerais savoir quel est le point de départ de la réflexion de qqn qui doit écrire un parser.

J'ai l'impression que flex/bison sont surtout adaptés à la rédaction de compilos qui produisent de l'assembleur. Peut être que je me trompe...
Peut être qu'une lecture ligne à ligne avec des strings et des tas de if va suffire? Peut être pas...

Enfin merci de me donner un point de vue assez général sur le sujet.

Régis




Pour le contexte :
Le mien doit prendre un langage à typage dynamique (scilab) à la syntaxe assez simple, et fournir du code c++ en sortie.
Je dispose d'une librairie qui me fournit les types (forts) vector / matrix ... qui sont les types de base de scilab.

Exemple :

Code Scilab :

Code:

---

1 2 3 4 5

N=1000; x=ones(N) ; y=ones(N) ; res = x'*y ; // produit scalaire

---

doit donner :

Code cpp :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include "myLib.h"   int main () { int N = 1000 ; myLib::vector<float> x(N, 1) ; myLib::vector<float> y(N, 1) ; float res = x*y ; return 0 ; }

---

flex/bison sont très générique et permettent de réaliser n'importe quel scaner/parseurs, mais par contre le code qu'ils génère est une horreur sans nom. Coco/R produit un code beaucoup plus lisible, et en C++, ce qui n'est pas la moindre de ses qualités.

La méthodologie est la suivante :

1) créer sa grammaire : c'est la première chose à faire, et ce n'est pas le plus facile. Il y a des tas de cas à gérer, et il faut faire en sorte que la grammaire soit utilisable. En fonction du système choisi, les constructions à utiliser peuvent être limitées (grammaires LL(k) contre grammaires LR(k), etc).

2) transposer sa grammaire dans l'outil : là, la simplicité d'utilisation est primordiale. Coco/R (décidément, j'en fait une grosse publicité) a un syntaxe très simple et très puissante, bien qu'ils se limites aux grammaires LL(1) (LL(k) grâce à son système de résolution de conflits). Dans un premier temps, on va faire le minimum vital pour vérifier que le parseur généré est capable de comprendre les fichiers qu'on va lui donner en entrée. Attention toutefois : le minimum vital en question peut nécessiter la définition d'actions sémantiques, notamment si on doit vérifier au moment de la compilation (i.e. la transformation d'un fichier en un autre) que les identificateurs utilisés existent, auquel cas il faudra prévoir une table des symboles.

3) une fois qu'on a vérifié que tous nos programmes en entrée fonctionnait, on étend le parseur avec des règles sémantiques qui permettent de produire le code (dans le cas d'un compilateur qui a pour but de générer du code objet, que celui-ci s'exécute ensuite dans une VM ou non ; il y a des chances qu'on passe entre temps par un AST (abstract syntax tree) dont les buts et utilisations sont multiples) où qui exécute certaines actions (dans le cas d'un interpréteur).

Ok merci beaucoup emmanuel !

Je vais donc tranquillement me mettre au boulot :D

A bientôt.

Régis