v0.8 2004/09/20 07:14:23 Bert Hubert PowerDNS BV

bert@powerdns.com

Jeffrey Sinclair jeff CHEZ bab POINT com Ce document tente vous vous aider �� commencer �� utiliser Lex and YACC

Bienvenue, cher lecteur. Quelle que soit la dur��e durant laquelle vous avez programm�� sous un environnement Unix, vous avez rencontr�� les programmes mystiques Lex et YACC, ou tels qu'ils sont connus des utilisateurs de GNU/Linux �� travers le��monde, Flex et Bison; o�� Flex est une impl��mentation de Lex par Vern Paxson et Bison la version GNU de YACC. Nous allons appeler ces programmes Lex et YACC dans ce document - les nouvelles versions sont compatibles "vers le haut", vous pouvez donc utiliser Flex et Bison pour essayer nos exemples. Ces programmes sont tr��s utiles, mais comme pour votre compilateur C, leur page "man" n'explique pas le langage qu'ils comprennent, ni comment les utiliser. YACC utilis�� en combinaison avec Lex est vraiment surprenant, cependant, la page "man" ne d��crit pas comment int��grer du code g��n��r�� par Lex dans votre programme en Bison.

Il existe de nombreux livres qui traitent de Lex et YACC. Lisez ces ouvrages de toute mani��re si vous souhaitez en savoir plus. Ils apportent beaucoup plus d'information que ce nous sommes en mesure de voir ici. Vous pouvez consulter la section ����lectures pour approfondir���� �� la fin. Ce document a pour but de vous aider �� vous en sortir lors de la cr��ation de vos premiers programmes avec Lex & YACC. La documentation fournie avec Lex & YACC est elle aussi excellente, mais peu p��dagogique. Elle est cependant compl��mentaires avec mon Howto, et est aussi r��f��renc��e �� la fin. Je ne suis absolument pas un expert de Lex & Yacc. lorsque j'ai commenc�� �� ��crire ce document, j'avais exactement deux jours de pratique. Tout ce que j'ai cherch�� �� faire, c'est rendre ces deux jours les plus simple possibles pour vous. N'attendez pas du HowTo qu'il vous montre comment coder proprement en Lex et YACC. Les exemples ont ��t�� laiss�� volontairement tr��s simples et il y a s��rement de meilleures mani��res de les ��crire. Si vous savez comment, s'il vous pla��t, contactez moi.

Notez que vous pouvez t��l��charger tous les exemples montr��s sous forme de code source. Visitez la Homepage pour plus de d��tails.

Copyright (c) 2001 by bert hubert. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, vX.Y or later (the latest version is presently available at http://www.opencontent.org/openpub/). Traduction �� titre informative et sans valeur juridique : Copyright (c) 2001, bert hubert. Ce programme ne peut ��tre distribu�� que selon les conditions g��n��rales ��tablies dans l'�� Open Publication License ��, vX.Y ou ult��rieure (la derni��re version est disponible �� http://www.opencontent.org/openpub/).

Utilis��s proprement, ces langages vous permettent d'analyser facilement des langages complexes. C'est un sacr�� coup de pouce lorsque vous souhaitez lire un fichier de configuration, ou que vous souhaitez ��crire un compilateur pour un langage que vous (ou n'importe qui d'autre) avez invent��. Avec un peu d'aide, ce que j'esp��re que ce document vous apportera, vous d��couvrirez finalement que vous n'��crirez plus jamais d'analyseur syntaxique �� la main: Lex & YACC sont les outils pour le faire.

M��me si ces programmes fonctionnent de mani��re optimale ensemble, ils servent chacun �� un but diff��rent. Les prochains chapitres expliqueront exactement l'action de chacun d'entre eux.

Ce programme g��n��re ce que l'ont appelle un analyseur lexical. Il s'agit d'une fonction qui prend comme argument un flux de caract��res, et d��s qu'il aper��oit un groupe qui correspond �� un mot clef, effectue une certaine action. Un exemple tr��s simple : %{ #include <stdio.h> %} %% stop printf("Stop command received\n"); start printf("Start command received\n"); %% La premi��re partie, entre les paires %{ et %}, est inclue directement dans la sortie. Nous avons besoin de cela, car nous utiliserons printf, qui est d��finit dans stdio.h, plus tard. Les parties sont s��par��es par %%, donc la premi��re ligne de la seconde section commence par le mot-clef ����stop����. A chaque fois que le mot-clef ����stop���� est rencontr�� dans l'entr��e, le reste de la ligne ( ici un appel �� printf() ) est ex��cut��. En plus de ����stop���� nous avons aussi d��finit ����start����, qui par ailleurs effectue sensiblement la m��me chose. Nous terminons la seconde partie avec %% encore. Pour compiler l'exemple 1, faire ceci: lex example1.l cc lex.yy.c -o example1 -ll si vous utilisez Flex, au lieu de Lex, vous pouvez avoir �� changer -|| en -lfl ans le script de compilation. RedHat 6.x et SuSE en ont besoin aussi, m��me en utilisant Flex au lieu de Lex ! Ceci g��n��rera un fichier ����exemple1����. Si vous le lancez, il attendra que de vous tapiez une entr��e. M��me si vous tapez une entr��e qui n'est pas ����match��e���� par un mot-clef (ici stop et start) it's output again. Si vous entrez 'stop', il affichera la sortie suivante ����stop command received����; Terminate with a EOF (^D). Vous pouvez vous demander comment fonctionnent ces programmes, car nous n'avons pas d��finit de fonction main(). Cette fonction est d��finit pour vous dans libl (liblex) que nous avons compil�� avec le programme gr��ce �� la commande -ll.

Cet exemple n'��tait pas tr��s utile en soit, et notre suivant ne sera pas mieux. Il va cependant nous montrer comment utiliser les expressions r��guli��res en Lex, qui seront tr��s utiles plus tard. Example 2: %{ #include <stdio.h> %} %% [0123456789]+ printf("NUMBER\n"); [a-zA-Z][a-zA-Z0-9]* printf("WORD\n"); %% Ce fichier Lex explique deux types de mots cl��s (symboles): WORD et NUMBER. Les expressions r��guli��res peuvent ��tre un peu intimidantes, mais avec un peu de travail, elles sont tr��s simples �� comprendre. Examinons le mot cl�� NUMBER: [0123456789]+ Cela signifie: une s��quence de un ou plus de caract��res du groupe {0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }. On aurait aussi pu faire plus court : [0-9]+ Maintenant, le mot cl�� WORD est un peu plus complexe: [a-zA-Z][a-zA-Z0-9]* a premi��re partie ne rep��re qu'un et un seul caract��re entre 'a' et 'z', ou entre 'A' et 'Z'.En d'autres termes, une lettre. Cette lettre initiale doit ensuite ��tre suivie par z��ro ou plus de caract��res qui sont soit une lettre, soit un chiffre. Pourquoi avoir utilis�� un ast��risque ici ? Le '+' signifie 1 ou plus de rep��rages, mais un mot peut tr��s bien n'��tre qu'un seul caract��re, que nous avons alors d��j�� match��. La seconde partie peut donc n'avoir rien �� matcher, nous ��crivons donc un '*'. De cette mani��re , nous avons sing�� le comportement de nombreux langages de programmation qui requi��rent qu'un nom de variable ����doive���� commencer par une lettre, mais puisse contenir des chiffres ensuite. En d'autres mots 'temperature1' est un nom valide, mais '1temperature��' ne l'est pas. Essayez de compiler Example2, tout comme Exemple1, et nourrissez le d'un peu de texte. Voici une session d'��chantillons: $ ./example2 foo WORD bar WORD 123 NUMBER bar123 WORD 123bar NUMBER WORD Vous pourriez aussi vous demander pourquoi il y a un retour �� la ligne dans la sortie. La raison est simple : il ��tait dans l'entr��e, n'a ��t�� match�� nul part, il appara��t donc dans la sortie. La page de man de Flex documente les expressions r��guli��res en d��tail. Beaucoup de gens trouvent que cellle des expressions r��guli��res de perl est aussi tr��s utile, m��me si Flex n'impl��mente pas tout ce que perl fait. V��rifiez que vous n'avez pas cr��e de match de taille nulle comme '[0-9]*', votre lexer pourrait ��tre perdu et pourrait commencer �� matcher des cha��nes vides en boucle

Imaginons que nous voulions analyser un fichier qui ressemble �� ceci: logging { category lame-servers { null; }; category cname { null; }; }; zone "." { type hint; file "/etc/bind/db.root"; }; On voit clairement un certain nombre de cat��gories (symboles) dans ce fichier: WORD, (mot) comme 'zone' et 'type' FILENAME, (nom de fichier) comme '/etc/bind/db.root' QUOTE, (guillemets)comme celles entourant le nom du fichier OOBRACE, (crochet ouvrant) { EBRACE, (crochet fermant) } SEMICOLON, (point virgule) ; Le fichier correspondant en Lex est Exemple 3: %{ #include <stdio.h> %} %% [a-zA-Z][a-zA-Z0-9]* printf("WORD "); [a-zA-Z0-9\/.-]+ printf("FILENAME "); \" printf("QUOTE "); \{ printf("OBRACE "); \} printf("EBRACE "); ; printf("SEMICOLON "); \n printf("\n"); [ \t]+ /* ignore whitespace */; %% Quand nous donnons notre ficher �� notre lexer g��n��r�� par ce fichier Lex (en utilisant example3.compile), nous obtenons: WORD OBRACE WORD FILENAME OBRACE WORD SEMICOLON EBRACE SEMICOLON WORD WORD OBRACE WORD SEMICOLON EBRACE SEMICOLON EBRACE SEMICOLON WORD QUOTE FILENAME QUOTE OBRACE WORD WORD SEMICOLON WORD QUOTE FILENAME QUOTE SEMICOLON EBRACE SEMICOLON Lorsque nous comparons ceci avec le fichier cit�� plus haut, il est clair que nous l'avons 'symbolis��e'. Chaque partie du fichier de configuration �� ��t�� analys��e, et convertie en symbole. Et c'est exactement ce donc nous avons besoin pour utiliser YACC Correctement.

Nous avons vu que Lex est capable de lire une entr��e arbitraire, et d'analyser ce qu'est chaque partie. C'est ce qu'on appelle l'analyse lexicale.

YACC peut analyser syntaxiquement un flux compos�� de symboles avec certaines valeurs. Cela d��crit parfaitement la relation entre YACC et Lex. Yacc n'a aucune id��e de ce que sont les 'flux en entr��e��', il a besoin de symboles au pr��alablement trait��s. Alors que vous pourriez ��crire vous m��me votre propre analyseur lexical, nous allons laisser Lex s'en charger. Une note sur les grammaires et les analyseurs syntaxiques. Lorsque YACC �� vu le jour, cet outil ��tait utilis�� pour analyser les fichier d'entr��e des compilateurs. Les programmes ��crits pour un langage de programmation ne sont pas ambigus (cad qu'ils n'ont qu'un seul sens). En tant que tel, YACC ne peut pas surmonter une ambigu��t�� ou un conflit d��calage/r��duction. Vous pourrez en apprendre plus sur YACC et les probl��mes d'ambigu��t�� ou les conflits d��calage/r��duction dans le chapitre 'Conflits��'.

Imaginons que nous ayons un thermostat que nous voulons contr��ler avec un langage simple. Un dialogue avec le thermostat pourrait ressembler �� ceci : heat on Heater on! heat off Heater off! target temperature 22 New temperature set! Les symboles que nous avons besoin de reconna��tre sont : heat, on/off (STATE), target, temp��rature, NUMBER. L'analyseur lexical Lex (Exemple 4) est : %{ #include <stdio.h> #include "y.tab.h" %} %% [0-9]+ return NUMBER; heat return TOKHEAT; on|off return STATE; target return TOKTARGET; temperature return TOKTEMPERATURE; \n /* ignore end of line */; [ \t]+ /* ignore whitespace */; %% Nous pouvons remarquer deux changements importants. Premi��rement, nous 'incluons' le fichier 'y.tab.h', et ensuite nous n'affichons plus rien, nous retournons les noms des ymboles. Ce changement est caus�� par le fait que nous fournissons d��sormais le tout �� YACC, ce qui n'a plus aucun rapport avec ce que nous obtenons �� l'��cran. Y.tab.h has definitions for these tokens. Mais d'o�� viens y.tab.h ? Il est g��n��r�� par YACC �� partir du fichier grammaire que nous sommes allons cr��er. Comme notre langage est tr��s basique, voil�� notre grammaire: commands: /* empty */ | commands command ; command: heat_switch | target_set ; heat_switch: TOKHEAT STATE { printf("\tHeat turned on or off\n"); } ; target_set: TOKTARGET TOKTEMPERATURE NUMBER { printf("\tTemperature set\n"); } ; La premi��re partie est ce que j'appelle la 'racine'. Elle nous explique que nous avons des commandes, et que ces commandes consistent en individual 'command' parts. Comme vous pouvez le voir, cette r��gle es tr��s r��cursive car elle contient encore le mot ��command����. Ce qui signifie que le programme est d��sormais capable de r��duire une s��rie de commandes une par une. Lisez le chapitre 'Comment fonctionnent Lex et YACC en d��tail��' pour des d��tails importants sur la r��cursivit��. la seconde r��gle d��finit ce qu'est une commande. Nous ne supportons que deux types de commande, la commande 'heat_switch' et la commande 'target_set'. C'est ce que le symbole |- signifie: une commande peut ��tre ou un 'heat-switch' ou un 'target-set'. Un heat-switch consiste en un symbole HEAT qui est simplement le mot 'heat' suivit d'un ��tat (que nous d��finirons dans le Fichier Lex comme 'on' ou 'off'). Plus compliqu��: le 'target_set' qui consiste en un symbole TARGET (le mot target), le symbole TEMPERATURE (le mot temperature) et un nombre.

La section pr��c��dente n'a montr��e que la partie grammaticale du fichier YACC, mais il y a plus. Voici l'en t��te que nous avons omis: %{ #include <stdio.h> #include <string.h> void yyerror(const char *str) { fprintf(stderr,"error: %s\n",str); } int yywrap() { return 1; } main() { yyparse(); } %} %token NUMBER TOKHEAT STATE TOKTARGET TOKTEMPERATURE La fonction yyerror() est appel��e par YACC si il trouve une erreur. Nous renvoyons simplement le message re��u, mais il y a des choses plus intelligente �� faire avec. Lisez la section ����lectures pour approfondir���� pour en savoir plus. La fonction yywarp() peut ��tre utilis��e pour continuer la lecture depuis un autre fichier. C'est appel��e �� EOF et vous pouvez ensuite ouvrir un autre fichier et renvoyer 0; ou renvoyer 1 qui indique qu'il s'agit de la fin. Pour en savoir plus, lisez le chapitre : 'Comment fonctionnent Lex et YACC en d��tail��'. Ensuite, il y a la fonction main(), qui ne fait rien de particulier, mais lance le processus La derni��re ligne d��finit simplement les symboles qui seront utilis��s. Ce sont les sorties qui utilisent y.tab.h si YACC est appel�� avec l'option -d <-- ici je ne suis pas sur d'avoir compris le sens de la phrase en anglais.

lex example4.l yacc -d example4.y cc lex.yy.c y.tab.c -o example4 Certaines choses ont chang��es. Nous appelons aussi YACC pour compiler notre grammaire, ce qui cr��e y.tab.c et y.tab.h. Nous appelons appelons ensuite Lex comme d'habitude. Lorsque nous compilons, nous retirons le drapeau -ll: nous avons d��sormais notre propre fonction main() et nous n'avons pas besoin de celle fournis par libl. Si vous obtenez une erreur indiquant que votre compilateur n'est pas capable de trouver 'yylval��', ajoutez ceci �� l'��xemple4.1, juste sous #include <y.tab.h>: extern YYSTYPE yylval; Ceci est expliqu�� dans le chapitre 'comment Lex et YACC fonctionnent en d��tail. Une session d'exemple : $ ./example4 heat on Heat turned on or off heat off Heat turned on or off target temperature 10 Temperature set target humidity 20 error: parse error $ Ce n'est pas vraiment ce que l'ont avait pr��vu d'obtenir, mais pour garder une courbe d'apprentissage praticable nous ne pouvons pas montrer toutes les possibilit��s en une fois.

Comme nous l'avons vu, nous analysons d��sormais syntaxiquement les commandes du thermostat correctement, et marquons m��mes les erreurs correctement. Mais comme vous pouvez l'avoir devin�� d'apr��s le titre le programme n'a aucune id��e de ce qu'il doit faire, it does not get passed any of the values you enter. Commen��ons par ajouter la possibilit�� de lire la nouvelle temp��rature cible. Pour faire cela, nous avons besoin de lire le NUMBER match�� dans l'analyseur lexical pour le convertir en valeur enti��re, qui pourra ensuite ��tre lue avec le YACC. A chaques fois que le Lex matche une cible, il place le texte match�� dans la suite de caract��res 'yytext'. YACC, lui, esp��re trouver une valeur dans la variable 'yylval'. Dans l'exemple 5, nous voyons la solution triviale: %{ #include <stdio.h> #include "y.tab.h" %} %% [0-9]+ yylval=atoi(yytext); return NUMBER; heat return TOKHEAT; on|off yylval=!strcmp(yytext,"on"); return STATE; target return TOKTARGET; temperature return TOKTEMPERATURE; \n /* ignore end of line */; [ \t]+ /* ignore whitespace */; %% Comme vous pouvez le constater, nous appelons atoi() sur yytext, et pla��ons le r��sultat dans yyval, o�� YACC peut le lire. Nous faisons �� peu pr��s la m��me chose pour le match STATE, nous le comparons �� 'on', et initialisons yylval �� 1 si c'est ��gal. Notez qu'avoir deux match separ��s pour 'on' et 'off' dans lex produirai un code plus rapide, mais j'ai voulu montrer une action plus complexe pour changer. Maintenant, nous devont apprendre YACC �� le supporter. Ce qui est appell�� yylval avec Lex est appel�� diff��remment avec YACC. Examinons la r��gle r��glant la nouvelle temperature cible: target_set: TOKTARGET TOKTEMPERATURE NUMBER { printf("\tTemperature set to %d\n",$3); } ; Pour acc��der �� la valeur de la troisi��me partie de la r��gle (cad, NUMBER), nous avons besoin d'utiliser $3. Quelque soit le moment du retour de yylex(), les contenus de yylval sont attach�� au terminal, qui peuvent ��tre atteint par le $-constructeur. <- je ne suis pas sur du sens Pour aller plus loin, observons la nouvelle r��gle du 'heat switch': heat_switch: TOKHEAT STATE { if($2) printf("\tHeat turned on\n"); else printf("\tHeat turned off\n"); } ; Si vous lancez maintenant l'exemple5, il prend en compte correctement ce que vous avez entr��.

Rappelons une partie du fichier de configuration que nous avons vu plus haut: zone "." { type hint; file "/etc/bind/db.root"; }; Souvenez vous que nous avons d��j�� ��crit un Lexer pour ce fichier. Tout ce dont nous avons besoin maintenant c'est d'��crire la grammaire de YACC et modifier l'analyseur lexical (aussi appel�� Lexer) pour qu'il renvoi les donn��es dans un format compr��hensible pour YACC. Dans l'analyseur lexicalde l'exemple6, nous avons : %{ #include <stdio.h> #include "y.tab.h" %} %% zone return ZONETOK; file return FILETOK; [a-zA-Z][a-zA-Z0-9]* yylval=strdup(yytext); return WORD; [a-zA-Z0-9\/.-]+ yylval=strdup(yytext); return FILENAME; \" return QUOTE; \{ return OBRACE; \} return EBRACE; ; return SEMICOLON; \n /* ignore EOL */; [ \t]+ /* ignore whitespace */; %% Si vous observez attentivement, vous pouvez voir que yylval est diff��rent ! Nous n'attendons plus de lui d'��tre un entier, mais nous acceptons le fait que ce soit un char *. Dans un but de simplicit��, nous utilisons strdup et gaspillons beaucoup de ressource m��moires. Veuillez noter que cela peut ne pas ��tre un probl��me dans beaucoup de cas, lorsque par exemple vous n'avez besoin d'analyser qu'un fichier, puis de quitter. Nous souhaitons stocker des cha��nes de caract��re, car nous ne travaillons presque qu'avec des noms : nom de fichiers et noms de zone?. Plus tard, dans un autre chapitre, nous expliquerons comment traiter diff��rents types de donn��es. Pour indiquer �� YACC le nouveau type de yylval, nous ajoutons cette ligne �� l'en-t��te de notre grammaire YACC: #define YYSTYPE char * La grammaire elle-m��me est encore une fois plus compliqu��e. Nous la d��coupons en parts pour la rendre plus digeste: commands: | commands command SEMICOLON ; command: zone_set ; zone_set: ZONETOK quotedname zonecontent { printf("Complete zone for '%s' found\n",$2); } ; Ceci est l'introduction, comprenant la racine r��cursive pr��c��demment cit��e. Veuillez noter que nous pr��cisons que chaque commande se termine par un ;. (et les commandes sont donc s��par��es par des ;). Nous d��finissons un type de commande : 'zone_set'. Elle consiste en un symbole ZONE (le mot 'zone'), suivit par un 'quotedname' et le 'zone content'. Ce 'zonecontent��' d��bute simplement : zonecontent: OBRACE zonestatements EBRACE Il a besoin de commencer avec un OBRACE, un crochet ouvert {. Puis suit les 'zonestatement's, suivits par un EBRACE, crochet ferm�� }. quotedname: QUOTE FILENAME QUOTE { $$=$2; } Cette section d��finit ce qu'est un quotedname : un FILENAME (nom de fichier) entre QUOTEs (guillemets). Puis il indique quelque chose de sp��cial: la valeur d'un symbole 'quotedname' est la valeur du FILENAME. Cela signifie que la valeur du quoted name est le nom du fichier sans les quotes C'est ce que fait la commande magique '$$=$2;' . Elle dit : ma valeur est la valeur de ma seconde partie. Alors que le quoted name est d��sormais referenc�� par d'autres r��gles, et que vous acc��dez �� sa valeur gr��ce au $-constructeur, vous voyez la valeur que nous avons fix�� ici avec $$=$2. Cette grammaire bute sur les noms de fichiers ne comportant pas de '.' ou de '/' zonestatements: | zonestatements zonestatement SEMICOLON ; zonestatement: statements | FILETOK quotedname { printf("A zonefile name '%s' was encountered\n", $2); } ; Il s'agit d'une instruction g��n��rale qui d��tecte tous les types d'instructions �� l'int��rieur des blocs 'zone'. Nous apercevons ici encore de la r��cursivit��. block: OBRACE zonestatements EBRACE SEMICOLON ; statements: | statements statement ; statement: WORD | block | quotedname Ceci d��finit un bloc et les instructions qui peuvent ��tre trouv��e �� l'int��rieur. Lorsque l'on ex��cute le tout, la sortie ressemble �� cela : $ ./example6 zone "." { type hint; file "/etc/bind/db.root"; type hint; }; A zonefile name '/etc/bind/db.root' was encountered Complete zone for '.' found

Bien que Lex & YACC soient ant��rieurs �� C++, il est possible de g��n��rer un parseur C++. Flex comprends une option pour g��n��rer un Lexer C++, mais nous ne l'utiliserons pas, car YAXX ne sait pas comment l'utiliser directement. Ma m��thode pr��f��r��e pour cr��er un parseur C++ est de faire g��n��rer �� Lex un fichier C clair, et de laisser YACC g��n��rer le code C++. Lorsque liez ensuite votre application, vous pouvez avoir quelques probl��mes car le code C++ fournit par d��faut ne sera pas capable de trouver les fonctions C, sauf si vous avez indiqu�� que ces fonction sont du C externe. Pour faire cela, faites un en-t��te C dans YACC, comme cela: extern "C" { int yyparse(void); int yylex(void); int yywrap() { return 1; } } Si vous voulez d��clarer ou changer yydebug, vous devez maintenant le faire comme ceci: extern int yydebug; main() { yydebug=1; yyparse(); } Cela est du �� la d��finition d'une r��gle en C++, qui ne permet pas plusieurs d��finitions de yydebug. Vous pouvez aussi avoir besoin de r��p��ter le #define de YYSTYPE dans votre ficher Lex �� cause du v��rificateur de type strict de C++. Pour compiler, faites quelque chose comme ceci : lex bindconfig2.l yacc --verbose --debug -d bindconfig2.y -o bindconfig2.cc cc -c lex.yy.c -o lex.yy.o c++ lex.yy.o bindconfig2.cc -o bindconfig2 A cause de l'option -o, y.tab.h est d��sormais appel�� bindconfig2.cc.h, donc prenez le en compte. Pour r��sumer: ne vous emb��tez pas �� compiler votre lexer en C++, laissez le en C. Faites votre parseur en C++ et expliquez �� votre compilateur que certaines fonctions sont des fonctions C avec des instructions externes.

Dans le fichier YACC, vous ��crivez votre propre fonction main(), qui appelle yyparse() �� un certain moment. La fonction yyparse()est cr����e pour vous par YACC, et finit dans y.tab.c. yyparse() lit un flux de symboles/paires de valeurs depuis yylex() , qui doit ��tre aliment��. Vous pouvez coder cette fonction vous m��me, ou laisser Lex le faire pour vous. Dans nos exemples, nous avons choisit de laisser ce travail �� Lex. Ce yylex() ��crit par Lex lit les caract��res depuis un FILE* file pointer appell�� yyin. Si vous ne d��finissez pas yyin, il est d��finit par d��faut sur l'entr��e standard. It outputs to yyout, which if unset defaults to stdout. Vous pouvez aussi modifier yin dans la fonction yywrap() qui est appel��e �� la fin d'un fichier. Elle vous permet d'ouvrir un autre fichier et de continuer le parsing. Si c'est le cas, faites lui retourner 0. Si vous voulez finir le parsing par ce fichier, faites lui retourner 1. Chaque appel �� yylex() retourne une valeur enti��re qui repr��sente un type de jeton. Cela indique �� YACC quel type de jeton est lu. Le jeton peut ��ventuellement avoir une valeur, qui devra ��tre plac��e dans la variable yyval. Par d��faut yylval est du type int, mais vous pouvez le surcharger depuis le fichier YACC en red��finissant #define YYSTYPE. Le lexer doit ��tre capable d'acc��der �� yylval. Pour faire cela, il doit ��tre d��clar�� dans le champ du lexer comme une variable externe. Le YACC original omet de le faire, donc vous devrez ajoutez la ligne suivante �� votre lexer: extern YYSTYPE yyval; , juste apr��s le #include <y.tab.h>. extern YYSTYPE yylval; Bison, que la plupart des gens utilise, le fait pour vous automatiquement.

Comme dit pr��c��demment, yylex() a besoin de renvoyer le type de jeton rencontr��, et de placer sa valeur dan yylval. Lorsque ces jetons sont d��finits avec la commande %token, il leur est assign�� un identifiant num��rique commen��ant �� 256. A cause de cela, il est possible d'avoir tous els caract��res ascii comme jeton. Imaginons que vous ��criviez une calculatrice, jusqu'�� maintenant, nous aurions ��crit le lexer comme ceci: [0-9]+ yylval=atoi(yytext); return NUMBER; [ \n]+ /* eat whitespace */; - return MINUS; \* return MULT; \+ return PLUS; ... Notre grammaire YACC aurait donc contenu suivant: exp: NUMBER | exp PLUS exp | exp MINUS exp | exp MULT exp Tout ceci est compliqu�� pour pas grand chose. En utilisant les caract��res comme abr��viations d'identifiants num��riques de jetons, nous pouvons r����crire notre lexer comme ceci : [0-9]+ yylval=atoi(yytext); return NUMBER; [ \n]+ /* eat whitespace */; . return (int) yytext[0]; This last dot matches all single otherwise unmatched characters. <- Cette version ne matche pas les caract��res seuls ou non match��s. Je n'arrive pas �� reformuler mais en gros y'a pas de match par default ? Notre grammaire YACC sera donc: exp: NUMBER | exp '+' exp | exp '-' exp | exp '*' exp Cette version est beaucoup plus courte et beaucoup plus ��vidente. Vous n'avez pas besoin de d��clarer ces symboles ascii avec %token dans l'en-t��te, ils sont pr��ts �� l'emploi. Un autre avantage avec cette construction est que Lex Lex va d��sormais matcher tout ce que nous lui envoyons ��� en ��vitant le comportement par d��faut qui est de r��p��ter les entr��e non match��es vers la sortie standard. Si un utilisateur de la calculatrice utilise ^, par exemple, il va d��sormais g��n��rer une erreur de parsing, au lieu d'��tre renvoy�� vers la sortie standard.

La r��cursivit�� est un aspect vital de YACC. Sans elle, vous ne pouvez pas sp��cifier que ce fichier consiste en une s��quence de commandes ou d'instructions ind��pendantes.YACC ne s'int��resse qu'a la premi��re r��gle, ou celle d��sign��e comme r��gle de d��part, par le symbole '%start'. La r��cursivit�� dans YACC existe en deux tendances : gauche ou droite. La r��cursivit�� �� gauche qui est celle que vous devriez utiliser la plupart du temps, ressemble �� ��a: commands: /* empty */ | commands command Cela signifie: une commande est soit vide, soit plusieurs commandes, suivies par une commande. La mani��re dont YACC travaille signifie qu'il peut d��sormais s��parer facilement des groupes de commandes et les r��duire. Comparons cela �� la r��cursivit�� �� droite, qui de mani��re plut��t confuse para��t meilleure aux yeux de beaucoup: commands: /* empty */ | command commands Mais c'est tr��s co��teux. Si on l'utilise comme r��gle %start, elle n��cessite que YACC conserve toutes les commandes dans la file sur le tas, ce qui peut prendre beaucoup de ressources m��moires. Utilisez donc quoi qu'il arrive la r��cursivit�� �� gauche lorsque vous analysez de longues instructions, comme des fichiers entiers. Il est parfois difficile d'��viter la r��cursivit�� �� droite, mais si vos instructions ne sont pas trop longues, il est naturel d'utiliser la r��cursivit�� �� gauche. Si vous quelque chose qui termine (et donc qui s��pare) vos commandes, la R��cursion �� droite para��t tr��s naturelle, mais reste tr��s co��teuse: commands: /* empty */ | command SEMICOLON commands La mani��re adroite de programmer ceci est d'utiliser la r��cursivit�� �� gauche (je n'ai trouv�� cela tout seul non plus): commands: /* empty */ | commands command SEMICOLON Les versions plus anciennes de ce Howto utilisaient par erreur la R��cursion �� droite. Markus Triska nous a gentiment inform�� �� ce sujet.

Actuellement, nous avons besoin de d��finir LE type yylval. Ce n'est cependant pas toujours appropri��. dans de nombreux cas nous avons besoin de pouvoir utiliser plusieurs types de donn��es. Retournons sur notre thermostat fictif, nous souhaitons peut ��tre ��tre capable de choisir un heater pour le contr��ler, comme ceci. heater mainbuiling Selected 'mainbuilding' heater target temperature 23 'mainbuilding' heater target temperature now 23 Cela demande �� yylval d'��tre une union, qui peut supporter les strings et les entiers ��� mais pas simultan��ment. Souvenez vous que nous avons pr��c��demment dit �� YACC de quel type yylval est suppos�� ��tre en d��finissant YYSTYPE. Il serai concevable de d��finir YYSTYPE ainsi comme une union, mais YACC a une meilleur m��thode pour faire cela: les instructions %union. A partir de l'exemple 4, nous ��crivons maintenant la grammaire YACC de l'exemple 7. Tout d'abord l'introduction: %token TOKHEATER TOKHEAT TOKTARGET TOKTEMPERATURE %union { int number; char *string; } %token <number> STATE %token <number> NUMBER %token <string> WORD Nous d��finissons notre union, qui contient seulement un nombre et un string. Puis en utilisant un une syntaxe ��tendue de %token nous expliquons �� YACC �� quelle partie de l'union chaque jeton doit acc��der. Dans ce cas, nous laissons le symbole STATE utiliser un entier comme pr��c��demment. Il en va de m��me pour le symbole NUMBER, que nous utilisons pour lire les temp��ratures. Le symbole WORD est lui par contre nouveau, et est d��clar�� pour avoir besoin d'un string. Le fichier Lexer change lui aussi un petit peu: %{ #include <stdio.h> #include <string.h> #include "y.tab.h" %} %% [0-9]+ yylval.number=atoi(yytext); return NUMBER; heater return TOKHEATER; heat return TOKHEAT; on|off yylval.number=!strcmp(yytext,"on"); return STATE; target return TOKTARGET; temperature return TOKTEMPERATURE; [a-z0-9]+ yylval.string=strdup(yytext);return WORD; \n /* ignore end of line */; [ \t]+ /* ignore whitespace */; %% Comme vous pouvez le voir, nous n'acc��dons plus directement �� yyval directement, nous ajoutons un suffixe indiquant �� quelle partie nous souhaitons acc��der. Nous n'avons cependant pas besoin de le faire dans la grammaire YACC, car YACC effectue le travail pour nous: heater_select: TOKHEATER WORD { printf("\tSelected heater '%s'\n",$2); heater=$2; } ; A cause de de la d��claration %token au dessus, YACC choisit automatiquement la partie 'string' dans notre union. Notez aussi que nous stockons une copie de $2 qui est plus tard utilis��e pour indiquer �� l'utilisateur �� quel heater il envoie la commande: target_set: TOKTARGET TOKTEMPERATURE NUMBER { printf("\tHeater '%s' temperature set to %d\n",heater,$3); } ; Pour plus de d��tails, Consultez l'exemple 7.y.

Particuliermeent lorsque l'on apprends, il est n��cessaire d'avoir des outils de d��boguage. Heureusement, YACC peut fournir ��norm��ment d'informations. Ces informations sont fournies au prix de temps syst��me, vous aurez donc besoin d'interrupteurs pour les activer. Lorsque vous compilez votre grammaire, ajoutez --debug et ���verbose �� votre ligne de commande. Dans votre l'en-t��te C de votre grammaire , ajoutez : int yydebug=1; Cela g��n��rera le fichier 'y.output' qui d��taille l'automate qui a ��t�� cr��e. Lorsque vous lancez le binaire g��n��r��, il renverra ��norm��ment d'informations sur ce qui se passe. Cela inclus dans quel ��tat se trouve l'automate et quels symboles sont en trains d'��tre lus. Peter jinks a ��crit une page sur le d��boguage qui contient quelques erreurs classiques et comment les r��soudre.

Sous le capot, votre analyseur syntaxique YACC fonctionne comme un automate fini. Comme le nom l'indique, cet automate (ou machine �� ��tats finis) peut se trouver dans diff��rents ��tats. Il y a ensuite des r��gles qui gouvernent ces transitions d'un ��tat �� l'autre. Tout d��bute avec la r��gle 'racine' mentionn��e plus t��t. Pour citer la sortie de l'exemple 7: state 0 ZONETOK , and go to state 1 $default reduce using rule 1 (commands) commands go to state 29 command go to state 2 zone_set go to state 3 By default, this state reduces using the 'commands' rule. This is the aforementioned recursive rule that defines 'commands' to be built up from individual command statements, followed by a semicolon, followed by possibly more commands. This state reduces until it hits something it understands, in this case, a ZONETOK, ie, the word 'zone'. It then goes to state 1, which deals further with a zone command: state 1 zone_set -> ZONETOK . quotedname zonecontent (rule 4) QUOTE , and go to state 4 quotedname go to state 5 The first line has a '.' in it to indicate where we are: we've just seen a ZONETOK and are now looking for a 'quotedname'. Apparently, a quotedname starts with a QUOTE, which sends us to state 4. To follow this further, compile Example 7 with the flags mentioned in the Debugging section.

A chaque fois que YACC vous informe de la pr��sence de conflits, vous pouvez avoir des soucis. R��soudre ces conflits semble un art qui peut vous apprendre beaucoup sur votre langage, plus que ce que vous n'auriez voulu en savoir. Ces probl��mes sont li��s �� l'interpr��tation de la s��quence des symboles. Supposons que l'on d��finisse un langage qui ait besoin d'accepter les deux commandes suivantes: delete heater all delete heater number1 Pour ce faire, d��finissons cette grammaire: delete_heaters: TOKDELETE TOKHEATER mode { deleteheaters($3); } mode: WORD delete_a_heater: TOKDELETE TOKHEATER WORD { delete($3); } Vous devez d��j�� sentir les ennuis arriver. L'automate commence par lire le mot 'delete' puis doit d��cider de la transition en se basant sur le symbole suivant. Le symbole suivant peut aussi bien ��tre un 'mode', sp��cifiant comment supprimer les 'heaters', ou le nom d'un 'heater' �� supprimer. Cependant le probl��me est que pour les deux commandes, le symbole suivant sera un 'WORD'. YACC n'a par cons��quent aucune id��e de ce qu'il doit faire. Cela conduit �� une alerte 'r��duction/r��duction' et une seconde alerte : le noeud delete_a_heater ne sera jamais atteint. Dans ce cas, le conflit est facilement r��solu en renommant la premi��re commande 'delete heaters all' ou en faisant de ALL un autre symbole. Mais parfois c'est plus difficile. Le fichier y.output g��n��r�� lorsque vous lancez YACC avec l'opion ���verbose peut ��tre d'une aide formidable.

GNU YACC (Bison) est fournit avec un fichier info (.info) tr��s int��ressant qui documente tr��s bien la syntaxe YACC. Il ne mentionne Lex qu'une seule fois, mais sinon il est tr��s bon. Vous pouvez lire les fichiers .info avec Emacs ou avec l'outil tr��s bien fait 'pinfo'. Il est aussi disponible sur le site de GNU : BISON Manual. Flex est fournit avec une page de man qui est tr��s utile si vous avez d��j�� une id��e approximative de ce que Flex fait. Le Flex Manual est aussi disponible en ligne. Apr��s cette introduction �� Lex et YACC, vous pouvez avoir besoin de plus d'informations. Je n'ai pas encore lu ces livres, mais ils semblent assez bon: Bison-The Yacc-Compatible Parser Generator Par Charles Donnelly et Richard Stallman. Un lecteur d'Amazon le trouve tr��s utile. Lex & Yacc Par John R. Levine, Tony Mason et Doug Brown. Consid��r�� comme une r��f��rence sur le sujet, bein qu'un peu vieux. Commentaires sur Amazon. Compilers : Principles, Techniques, and Tools par Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman. Le 'Dragon Book'. De 1985 et ils continuent de le r��imprimer. Consid��r�� comme la base sur la construction de compilateurs.. Amazon. Thomas Niemann a ��crit un document expliquant comment ��crire des compilateurs et des calculatrices avec Lex et YACC. Vous pouvez le trouver ici. La newsgroup mod��r��e comp.compilers peu aussi ��tre tr��s utile, mais gardez �� l'esprit que les gens l�� bas ne sont pas une hotline d��di��e aux parsers. Avant de poster, lisez leur page et plus sp��cialement la FAQ. Lex - A Lexical Analyzer Generator par M. E. Lesk and E. Schmidt est l'une des sources de r��f��rence. Il peut ��tre trouv�� ici. YACC: Yet Another Compiler Compiler par Stephen C. Johnson est l'une des sources de r��f��rence. Il peut ��tre trouv�� ici. Il contient des astuces sur le style.

Pete Jinks <pjj%cs.man.ac.uk> Chris Lattner <sabre%nondot.org> John W. Millaway <johnmillaway%yahoo.com> Martin Neitzel <neitzel%gaertner.de> Sumit Pandaya <sumit%elitecore.com> Esmond Pitt <esmond.pitt%bigpond.com> Eric S. Raymond Bob Schmertz <schmertz%wam.umd.edu> Adam Sulmicki <adam%cfar.umd.edu> Markus Triska <triska%gmx.at> Erik Verbruggen <erik%road-warrior.cs.kun.nl> Gary V. Vaughan <gary%gnu.org> (read his awesome Autobook) Ivo van der Wijk (Amaze Internet)