Tutoriel sur la mise en place d'une grammaire avec ANTLR

Une grammaire spécifie les mots-clés (encore appelés tokens) utilisables dans un langage et décrit les constructions utilisant ces mots qui sont admises par ledit langage. Pour réaliser les analyses lexicale et syntaxique, il faut spécifier une grammaire qui décrit la façon de regrouper le flux de caractères en un flux de tokens puis d'analyser le flux de tokens sortant.
Le mot token est un anglicisme utilisé pour désigner une entité (ou unité ) lexicale , dans le cadre de l' analyse lexicale .

Il existe, en fait, trois tâches distinctes que l'on souhaiterait effectuer à l'aide d'une grammaire : la reconnaissance , qui correspond au calcul de l'appartenance d'un mot à un langage ; l'analyse (ou le parsage), qui correspond au calcul de tous les arbres d'analyse possibles pour un énoncé ; la génération, qui correspond à la production de tous les mots du langage décrit par la grammaire.

L'analyse lexicale doit permettre de déterminer correctement les chaînes comprises dans le texte source. Le texte source est fourni à l'analyseur caractère par caractère. Ce dernier a pour travail de quantifier le groupe de caractères significatifs et de le catégoriser au point qu'il ait un sens pour l'analyseur syntaxique. Tout caractère ou groupe de caractères ainsi quantifié est appelé token.

Ainsi dans l'instruction Pascal suivante :

aire := base ∗ hauteur/2

L'analyse lexicale reconnaît les lexèmes suivants :

La tâche principale d'un analyseur lexical (appelé lexer ou tokenizer ou encore scanner) est de lire les caractères d'entrée et de produire comme résultat une suite d'unités lexicales que l'analyseur syntaxique va utiliser. C'est en général un sous-module de l'analyseur syntaxique qui lui commande la prochaine unité lexicale à extraire.

L'analyse syntaxique regroupe les unités lexicales en structures grammaticales en suivant les règles figurant dans une grammaire. En effet, le lexer regroupe une suite de caractères qu'il reconnaît dans le flux d'entrée selon une sémantique individuelle ; il ne considère pas la sémantique globale de tout le flux d'entrée. Ceci est le rôle de l'analyseur syntaxique qui organise les tokens qu'il reçoit en des suites grammaticalement correctes.

Un analyseur syntaxique (parser) prend en entrée une chaîne d'unités lexicales fournie par l'analyseur lexical et détermine si celle-ci fait partie du langage en construisant l'arbre syntaxique correspondant.

Antlr a trois cas d'utilisation principaux. Il peut être utilisé pour implémenter :

• un validateur ou reconnaisseur. Antlr génère le code qui permet de valider si le texte d'entrée respecte les règles de grammaire. Ici, la grammaire n'intègre pas d'actions (instructions écrites dans le langage cible) ni de règles de réécriture ;
• un processeur. Antlr génère du code qui valide et traite le texte d'entrée. La grammaire intègre des actions qui peuvent être des instructions de calcul, des accès à une base de données, etc. Cependant, il n'y a pas de règle de réécriture ;
• un traducteur. Antlr génère le code qui valide et traduit le texte d'entrée dans un autre format. Par exemple, il peut servir à traduire un texte écrit dans un langage en un texte écrit dans un autre langage. Ici, on retrouvera des actions, notamment les instructions d'affichage (println).

À partir d'une grammaire spécifiée sous le formalisme adéquat, Antlr peut générer des analyseurs écrits dans plusieurs langages cibles. Comme langages cibles, on peut citer : C++, Java, Python, C #.

BNF et EBNF sont à la base de la définition de la syntaxe des règles sous Antlr.

John Backus, créateur de Fortran, a conçu en 1959 une notation formelle permettant de décrire la syntaxe de n'importe quel langage. Elle fut utilisée à l'époque pour présenter la syntaxe d'Algol 58. Peter Naur a ensuite repris ses travaux en préparation à Algol 60, et ses modifications font depuis partie intégrante de la notation BNF : Backus Naur Form.

BNF se base sur un nombre donné de métasymboles, avec lesquels décrire une syntaxe. Ces métasymboles sont combinés à des symboles « terminaux » (catégories définies par la syntaxe) et « non terminaux » (mots-clés du langage lui-même). Il permet par exemple l'usage des symboles suivants : 

Par exemple, pour définir les voyelles disponibles dans l'alphabet : 

voyelle ::= "A" | "E" | "I" | "O" | "U" ;

L a notation BNF a ensuite été étendue sous le nom EBNF (Extended BNF). Cette extension permettait l'usage d'une syntaxe proche des expressions régulières pour décrire certains aspects, comme la répétition ou le regroupement de blocs. 

Depuis lors, la plupart des langages informatiques sont décrits suivant cette notation. EBNF se présente comme un métalangage concis et précis, idéal pour présenter toutes les facettes d'une syntaxe. Il interdit toute forme d'ambiguïté concernant l'interprétation de la spécification.

Pour réaliser les analyses lexicale et syntaxique avec Antlr, il faut :

1. Créer un fichier d'extension .g définissant les unités lexicales et syntaxiques de la grammaire. Antlr génèrera lui-même par la suite les classes correspondant au lexer et au parser ;
2. Créer et paramétrer un fichier Build.xml qui définit les actions à effectuer lors de la compilation des fichiers .g ;
3. Utiliser le compilateur Ant pour générer les analyseurs spécifiés dans la grammaire ;
4. Définir un programme principal dans le langage cible qui utilisera les analyseurs (lexer et le parser) générés pour effectuer le travail souhaité.

Une grammaire Antlr est constituée de plusieurs rubriques dont certaines sont optionnelles. La structure générale est la suivante :

Header {
/* le texte mis dans cette rubrique s'affichera tel quel dans toutes les classes définies dans ce fichier. Par exemple, nous y mettrons le nom du package auquel appartiendront toutes les classes générées */
}
{ /* Le texte de cette rubrique (non nommée) s'affichera tel quel au début de la classe qui sera générée à partir de la définition de classe qui suit */ 
// Nous y inscrirons par exemple les importations de packages.
}
class <nom_analyseur> extends <nom_classe_mere>

options{ // mettre ici les options spécifiques à l'analyseur }
tokens {
      // définir ici les tokens imaginaires ou les littéraux
      }
 <nom_regle1>: corps de la regle;
                         &#8230;
<nom_reglen>: corps de la regle;
/* la définition de la dernière règle marque la fin de la grammaire */

Une grammaire peut contenir plusieurs classes définies dans le même fichier. Dans ce cas, la portée d'une classe s'étend de sa déclaration jusqu'à la déclaration de la prochaine classe. Par exemple, il est de coutume de définir dans le même fichier la classe qui générera l'analyseur lexical et la classe qui générera l'analyseur syntaxique. Cependant, rien ne nous empêche de les définir dans des fichiers distincts.

Une règle définit une construction lexicale ou syntaxique reconnaissable par l'analyseur et éventuellement les actions à envisager lorsqu'une telle construction est rencontrée. Une telle construction peut aussi bien utiliser les constructions d'autres règles. Une règle est identifiée par un nom.

L'écriture d'une règle de la grammaire obéit au formalisme suivant :

Nom_de_la-regle[arguments] returns [valeur_de_retour]
options{ // les options liées uniquement à cette règle }
: // corps de la règle...
;

Dans le corps d'une règle, des formalismes sont utilisés pour caractériser la multiplicité d'une expression dans une construction. Ces formalismes sont :

• (expression) * : zéro ou plus. Ceci signifie que l'expression entre parenthèses peut être rencontrée zéro ou plusieurs fois dans la construction à reconnaître ;
• (expression) + : un ou plus. Ceci signifie que l'expression entre parenthèses peut être rencontrée une ou plusieurs fois dans la construction à reconnaître ;
• (expression) ? : zéro ou un. Ceci signifie que l'expression entre parenthèses peut être rencontrée une fois ou ne pas du tout être rencontrée dans la construction à reconnaître.

Nombre_decimal:
                           ('0' .. '9')+(',' ('0'..'9')+)?
                          ;

Lorsque plusieurs constructions se rapportent au même lexème, au lieu de définir plusieurs règles, il est judicieux de les regrouper dans une seule règle à plusieurs alternatives. Les alternatives sont séparées les unes des autres par un "|" dans le corps de la règle.

nom-regle[arguments] returns [valeur_de_retour]
options{ // les options liées uniquement à cette règle }
  : alternative 1
  | alternative 2
  | …
  | alternative n
  ;

Exemple

Pour qu'un analyseur reconnaisse les espacements (retour à la ligne, retour chariot, tabulation, etc.) dans le flux d'entrée, au lieu de définir une règle pour chaque type d'espacement, il est préférable de définir une seule règle à plusieurs alternatives comme suit :

White_Space
    : ' ' 
    | '\t' 
    | '\r' '\n' 
    | '\n' 
  ;

Vous avez pu remarquer dans la structure d'une grammaire qu'il figure plusieurs endroits dans lesquels on peut définir des options. En effet, les options permettent de donner certaines fonctionnalités à notre grammaire. Elles peuvent concerner toute la grammaire, juste une classe ou bien être spécifique à une règle.

Dans la section Options d'une grammaire ANTLR, vous pouvez spécifier une série de clé/valeur qui modifient la façon dont ANTLR génère du code. Ces options affectent globalement tous les éléments contenus dans la grammaire, sauf si vous les annulez dans une règle. Ce paragraphe décrit toutes les options disponibles.

La section des options doit venir après l'en-tête de la grammaire et doit avoir la forme suivante :

options {
nom1 = valeur1;
nom2 = valeur2;
...
}

Les noms des options sont toujours des identificateurs, mais les valeurs peuvent être des identificateurs, des chaînes de littéraux entre des guillemets simples, des nombres entiers, ou le littéral spécial * (l'astérisque souvent utilisable uniquement avec l'option k). Les valeurs sont toutes des littéraux et, par conséquent, ne peuvent pas être des noms d'option. Pour les chaînes littérales formées d'un seul mot comme « Java », vous pouvez l'écrire tout simplement, comme indiqué ci-après :

options {

language=Java;

}

La liste qui suit résume les options ANTLR au niveau de la grammaire.

Language

Précisez le langage cible dans lequel ANTLR devra générer les analyseurs.

ANTLR utilise le CLASSPATH pour trouver le répertoire org/antlr/ codegen/ templates/Java  ; dans ce cas, c'est Java le langage cible, et c'est lui par défaut.

Output

Générer des modèles de sortie, un modèle ou des arbres AST. Cette option est disponible uniquement pour les grammaires qui contiennent des analyseurs syntaxiques et un analyseur d'arbres. La valeur par défaut est de ne rien générer.

Backtrack

Lorsque sa valeur est True, cette option indique que ANTLR devrait revenir lorsque l'analyse statique de la grammaire LL (*) ne parvient pas à obtenir une décision déterministe. Cette option est habituellement utilisée en conjonction avec l'option memoize. La valeur par défaut est False.

Memoize

Enregistrer les résultats partiels d'analyse pour garantir que pour tout retour en arrière, l'analyseur n'analyse jamais la même entrée avec la même règle plus d'une fois. Ceci garantit une vitesse d'analyse linéaire au prix de la mémoire non linéaire. La valeur par défaut est False.

tokenVocab

Indiquez comment ANTLR devrait nommer l'ensemble de tokens prédéfinis ou générés. Cela sera nécessaire pour une grammaire qui veut utiliser les tokens d'une autre. Typiquement, une grammaire d'arbre utilisera les tokens de la grammaire de l'analyseur qui crée ses arbres. La valeur par défaut aucun.

rewrite

Lorsque la sortie de votre traducteur ressemble beaucoup à l'entrée, la solution la plus simple consiste à modifier le tampon d'entrée en place. Recréer toutes les entrées avec des actions juste pour modifier une petite partie est très fastidieux. Rewrite s'utilise conjointement avec l'option « output = Template ». Lorsque vous utilisez « rewrite = true », l'analyseur remplace également l'entrée à traiter par la règle avec le modèle. La valeur par défaut est faux.

SuperClass

Spécifie la superclasse de l'analyseur généré. Ce n'est pas une super grammaire ! Cette option affecte seulement la génération du code. La valeur par défaut est Lexer, Parser, ou TreeParser selon le type de grammaire.

Filter

À utiliser pour le LEXER uniquement. Toutes les règles du lexer sont essayées dans l'ordre indiqué, à la recherche d'une partie du flux d'entrée. Après la recherche de la règle convenable, la méthode nextToken () retourne le Token généré de cette règle. Si aucune règle ne correspond, le lexer consomme un seul caractère et continue à chercher la règle convenable. La valeur par défaut False.

K

Limite l'analyseur généré de cette grammaire à utiliser une profondeur maximale d'anticipation de la valeur de k. Ceci transforme l'analyse LL(*) classique en une analyse LL(k). La valeur par défaut est * pour une grammaire LL(*).

Voici quelques exemples d'options

K = 2; // Mettre la valeur d'anticipation à 2
tokenVocabulary = Calco; // Appeler le vocabulaire généré "Calco"
defaultErrorHandler = false; // Ne pas générer les erreurs du parser.

Deux règles sont ambigües lorsqu'elles commencent par les mêmes caractères. Par exemple, il sera difficile pour l'analyseur de savoir laquelle des règles suivantes appliquer lorsqu'il rencontre le caractère ‘a' dans le flux d'entrée.

RULE1 : "ab" ;

RULE2 : "ac" ;

Pour lever les ambigüités, deux techniques peuvent être utilisées : la valeur d'anticipation et le prédicat sémantique.

3-6-a. La valeur d'anticipation▲

3-6-b. Le prédicat sémantique▲

DOB 
  : ('0'..'9' '0'..'9' '/')=>
     (('0'..'9')('0'..'9')'/')(('0'..'9')('0'..'9')'/')('0'..'9')('0'..'9')
  | ('0'..'9')+
  ;

Antlr permet d'ajouter aux règles des instructions écrites dans le langage cible. Ces instructions sont appelées actions.

Une action est définie entre accolades et peut être ajoutée :

• au début de la règle . Ainsi l'action sera exécutée lorsque l'analyseur rencontrera cette règle ;
• dans le corps de la règle  : l'action sera exécutée pendant le traitement de la règle.

Exemple

ENTIER {System.out.println ("un entier est rencontré"); }// action au début 
         : (‘0'…'9')+ {System.out.println ("traitement de l'entier"); }
                                                                           // action dans le corps                                      
          ;

Une action peut être constituée d'instructions simples ou d'une suite d'instructions plus ou moins complexes portant aussi bien sur des opérations mathématiques que sur des accès à des fichiers ou à une base de données. Cependant, pour la lisibilité et l'efficacité de la grammaire, il faut éviter d'ajouter des actions complexes ou trop longues. Il vaudrait mieux définir les traitements par des procédures dans un autre fichier ou paquetage et appeler ces procédures comme actions dans les règles.

L'analyseur lexical définit les règles qui seront appliquées pour le regroupement des flux de caractères en flux de tokens. C'est une sous-classe de la classe Lexer. Par convention, le nom des règles doit être en majuscules.

La syntaxe de définition d'un analyseur lexical est la suivante :

Class nom_de_la_classe extends Lexer; 
options{ // ici les options spécifiques au lexer }
tokens{
  // Définir ici les tokens imaginaires ou  littéraux
   }
/*Définition des règles de l'analyseur*/
REGLE1: corps de la règle;
          ….
REGLE_N: corps de la règle;

L'analyseur syntaxique définit les règles de regroupement des tokens en constructions syntaxiquement correctes. C'est une sous-classe de Parser. Le nom des règles doit être de préférence en minuscules.

Class nom_de_la_classe extends Parser; 
options{ // ici les options spécifiques au Parser}
tokens{
     // Définir ici les tokens imaginaires ou  littéraux
  }
/*Définition des règles de la classe ici (voir paragraphe suivant pour la syntaxe)*/
regle1: corps de la règle;
          ….
regle n: corps de la règle;

Lors de l'écriture des règles dans les analyseurs lexical et syntaxique, on peut demander la génération automatique d'un arbre syntaxique. Il suffit de définir l'option

Build AST =true;

dans la partie Options de l'analyseur syntaxique.

Cet arbre syntaxique constitue aussi un flux d'entrée dont les tokens sont les nœuds de l'arbre et les constructions syntaxiques sont les branches ou les sous-arbres. Pour analyser ce nouveau flux de nœuds, Antlr a prévu l'analyseur d'arbre.

L'analyseur d'arbre hérite de la classe TreeParser.

Class nom_de_la_classe extends TreeParser; 
options{ // ici les options spécifiques au Parser}
tokens{
   // Définir ici les tokens imaginaires ou  littéraux
 }
/*Définition des règles de la classe ici (voir paragraphe suivant pour la syntaxe)*/
regle1: corps de la règle;
          ….
regle n: corps de la règle;

Nous reviendrons sur la construction et l'analyse de l'arbre syntaxique dans une prochaine édition.

Le fichier Build.xml définit les tâches qui seront exécutées par Apache Ant pour générer les analyseurs à partir de la grammaire Antlr. Le paramétrage d'un fichier build.xml peut faire l'objet d'un tutoriel à lui seul. Cependant, le moins qu'on puisse retenir est qu'il est organisé en trois rubriques :

• dans la rubrique Properties définir les variables à utiliser dans les autres rubriques. Ces variables contiennent notamment les chemins des répertoires. Par exemple, les variables « grammar.dir » et « parser.projet » ci-dessous contiennent les chemins vers le fichier grammaire et vers le dossier qui stockera les analyseurs générés ;
• dans la rubrique Tasks, définir les tâches à exécuter par Ant. La tâche que nous définirons est « antlrTask » qui compilera la grammaire ;
• dans la rubrique Target, préciser les cibles à atteindre pour accomplir ces tâches. Dans notre exemple, trois cibles ont été précisées : la cible « antlrproject » pour la génération des analyseurs, la cible « deleteAntlrProject » pour supprimer les fichiers générés et la cible « regenAntlrProject » qui est la cible par défaut. Elle efface les anciens analyseurs générés puis en génère de nouveaux.
  La ligne qui précède ces trois rubriques précise le nom du projet (calculatriceANTLR), la cible par défaut à atteindre (regenAntlrProject) et le répertoire racine (« . » , c'est-à-dire le répertoire courant, celui qui contient le fichier Build.xml).
  À titre d'illustration, voici le fichier Build.xml que nous utiliserons dans le cas pratique de la section suivante.

<?xml version="1.0" encoding="UTF-8"?>
 
<project name="calculatriceANTLR" default="regenAntlrProject" basedir=".">
 <!-- ######### PROPERTY ##############-->
       
       <!-- set global properties for this build -->
       <property name="src.dir" value="src" />
       <property name="grammar.dir" value="${src.dir}/main/ant" />
       <property name="lib.dir" value="lib" />
       <property name="parser.project" value="${src.dir}/main/java/analyseur" />
 
       <!-- ############### TASKS ##################-->
       <taskdef name="antlrtask"     
             classname="org.apache.tools.ant.taskdefs.optional.ANTLR">
             <classpath>
                    <pathelement path="${compile_classpath}"/> 
             </classpath>
       </taskdef>
 
       <!-- ########### TARGETS ####################-->
      <target name="antlrProject">
             <!-- Calculator grammar /-->
           <antlrtask target="${grammar.dir}/grammar.g"  
            outputdirectory="${parser.project}" />
      </target>
 
    <target name="regenAntlrProject" depends="deleteAntlrProject, antlrProject" />
             
     <target name="deleteAntlrProject">
             <delete>
                    <fileset dir="${parser.project}" />
             </delete>
     </target>
</project>

5-2-a. Installation du compilateur Ant▲

5-2-b. Compiler le build.xml▲

Une fois la compilation réussie, Ant génère un ensemble de fichiers. Il s'agit notamment :

• d'une classe pour le parser ;
• d'une classe pour le lexer ;
• d'une ou plusieurs classes pour les tokens générés XXXTokensType.java.

Le lexer et le parser générés doivent être maintenant exploités dans le programme principal pour effectuer le travail d'analyse attendu. En Java, l'exploitation des analyseurs générés se fait en trois étapes :

1. Créer un objet de la classe de l'analyseur lexical à partir d'un flux d'entrée ;
2. Créer un objet de la classe de l'analyseur syntaxique à partir de l'objet analyseur lexical ;
3. Appeler la première méthode de l'analyseur syntaxique générée pour lancer l'analyse. Cette méthode correspond en fait à sa première règle dans la grammaire. Comme cet appel peut générer des erreurs, il est commode de le faire dans un bloc « try...catch » comme suit :

public static void main (String [] args) {
String expression
    /*1- création  de l'analyseur lexical à partir du flux d'entrée*/
       XXXLexer lexer = new  XXXLexer(new StringReader(expression)); 
    /* 2- Création d'un analyseur syntaxique à partir de l'analyseur lexical */  
 CalculatriceParser parser = new CalculatriceParser(lexer);
        try {
    / * 3- Appel de la première règle de l'analyseur syntaxique */                   
                     parser.regle1();
                       }   catch(Exception e) 
                       {
                             System.out.println("Erreur de saisie"); 
                       }
 //………. suite du programme principal

Tout d'abord, vous devez vous assurer que le compilateur du langage cible (ici le JDK) est bien installé, ainsi que l'EDI (Eclipse).

Nous voulons créer un projet Maven sous Eclipse, mais vous pouvez aussi vous contenter d'un projet Java simple. Nous choisissons un projet Maven pour la simple raison que le plugin Apache Maven facilite l'organisation et l'assemblage d'un projet en gérant les dépendances entre les différents modules.

Au cas où vous souhaitez aussi vous en servir, vous procéderez à l'installation de Maven en suivant la procédure suivante :

1. Télécharger Maven dans le site http://maven.apache.org/ ;
2. Décompresser le fichier téléchargé dans un répertoire de votre ordinateur ;
3. Définir une variable d'environnement M2_HOMEavec pour valeur le chemin du répertoire dans lequel vous avez installé Maven ;
4. Définir une variable d'environnement utilisateur M2avec pour valeur%M2_HOME%\bin;
5. Créer ou mettre à jour la variable d'environnement PATH avec pour valeur %M2%;
6. En ligne de commande, exécuter mvn versionpour vérifier que l'installation s'est passée correctement.

En suivant les recommandations du paragraphe 1.6, nous allons procéder en cinq étapes :

1. Création un projet sous Eclipse ;
2. Création des packages. Dans un package (Application) de notre projet nous définirons deux classes : une classe Tools contenant les fonctions arithmétiques (addition, multiplication, division et soustraction) et une classe principale (Frame) implémentera l'interface graphique. Un autre package (Parser), accueillera les classes générées par Antlr ;
3. Écriture de la grammaire dans un fichier .g ;
4. Paramétrage du fichier build.xml ;
5. Génération et exploitation des analyseurs.

6-3-a. Création d'un nouveau projet sous Eclipse▲

6-3-b. Création des packages▲

6-3-c. Écriture de la grammaire▲

- L'analyseur lexical

Pour ce qui est de notre projet de calculatrice, il faut d'abord recenser les lexèmes à reconnaître dans une expression à calculer. En effet, l'utilisateur de la calculatrice aura à saisir des nombres entiers et des opérateurs, avec éventuellement des espaces. Notre analyseur lexical devra donc définir des règles pour la reconnaissance de ces lexèmes. Sa structure est la suivante :

Un analyseur lexical pour notre projet

Sélectionnez

class CalculatriceLexer extends Lexer
Options {
 K=1 ; 
filter = true ;
}
 INT
     : (‘0'..'9')+  // un entier est constitué d'un ou plusieurs chiffres décimaux
    ;
PLUS : ‘+' ;
MINUS : ‘-‘ ;
PRODUCT : ‘x' ;
DIV : ‘/' ;
WS      // cette règle permet de reconnaître les espacements 
   :  
    ( ' ' 
    | '\t' 
    | '\r' '\n' { newline(); } 
    | '\n'      { newline(); }
    ) 
{ $setType(Token.SKIP); } // ne pas considérer ces espacements comme tokens
  ;

- L'analyseur syntaxique

Le parser de notre projet devra être en mesure de reconnaître des expressions qui traduisent une addition, une soustraction, une multiplication ou une division.

Un analyseur syntaxique pour notre projet

Sélectionnez

class CalculatriceParser extends Parser;
 
options
{
       exportVocab=CALCO;
       buildAST=false;
      k=2;  
}
{      
public int resultat; // cette variable stockera le résultat de l'opération
}
expr
       : addExpr|subExpr|multExpr|divExpr // l'expression à analyser sera soit une
                                         // addition, une soustraction, une multiplication ou une division
       ;
addExpr
    {int n,m;}
       : (a:INT PLUS b:INT)
         { n=Integer.parseInt(a.getText()); // transformation de la chaine de caractères en entier
           m=Integer.parseInt(b.getText());
           resultat=sum(n,m);
           }
       ;
subExpr 
       {int n,m;}
       : (a:INT MINUS b:INT)
         { n=Integer.parseInt(a.getText());
           m=Integer.parseInt(b.getText());
           resultat=substract(n,m);
           }
       ;
multExpr 
       {int n,m;}
       : (a:INT PRODUCT b:INT)
         { n=Integer.parseInt(a.getText());
           m=Integer.parseInt(b.getText());
           resultat=multiply(n,m);
          }
       ;      
divExpr 
       {int n,m;}
       : (a:INT DIVIDE b:INT)
         { n=Integer.parseInt(a.getText());
           m=Integer.parseInt(b.getText());
           resultat=divide(n,m);
           }
       ;

Les fonctions add(), substract(), multiply() et divide() sont implémentées dans la classe Tools du paquetage Application. On aurait bien pu se contenter d'effectuer ces opérations directement dans la grammaire. Mais souvenez-vous que l'objectif est de ne pas surcharger les règles de la grammaire par des actions aux longues instructions.

Nous enregistrerons notre grammaire sous le nom grammar.g dans le répertoire « src/Ant » de notre projet Eclipse. La grammaire complète se trouve dans le code complet de l'application que vous téléchargerez.

6-3-d.  Paramétrage du Build.xml ▲

<?xml version="1.0" encoding="UTF-8"?>
 
<project name="calculatriceANTLR" default="regenAntlrProject" basedir=".">
 <!-- ############################# VARIABLES ##############################-->
       
       <!-- set global properties for this build -->
       <property name="src.dir" value="src" />
       <property name="grammar.dir" value="${src.dir}/main/ant" />
       <property name="lib.dir" value="lib" />
       <property name="parser.project" value="${src.dir}/main/java/analyseur" />
 
       <!-- ############################# TASKS ##############################-->
       <taskdef name="antlrtask"     
             classname="org.apache.tools.ant.taskdefs.optional.ANTLR">
             <classpath>
                    <pathelement path="${compile_classpath}"/> 
             </classpath>
       </taskdef>
 
       <!-- ############################ TARGETS #############################-->
      <target name="antlrProject">
             <!-- Calculator grammar /-->
           <antlrtask target="${grammar.dir}/grammar.g"  
            outputdirectory="${parser.project}" />
      </target>
 
    <target name="regenAntlrProject" depends="deleteAntlrProject, antlrProject" />
             
     <target name="deleteAntlrProject">
             <delete>
                    <fileset dir="${parser.project}" />
             </delete>
     </target>
</project>

6-3-e. La génération▲

Vous pouvez générer les analyseurs à partir de la grammaire en utilisant le compilateur Ant ou Maven.

- Avec le compilateur Ant

En ligne de commande, se placer dans le répertoire qui contient le fichier build.xml et exécuter la commande ant .

- Avec Maven

En ligne de commande, se placer dans le répertoire qui contient le projet et exécuter la commande mvn clean package .

Une fois la compilation réussie, vous pouvez observer les analyseurs générés en ouvrant le package « Analyseurs » du projet. Vous pourrez alors observer :

• une classe pour le parser : CalculatriceParser.java ;
• une classe pour le lexer : CalculatriceLexer.java ;
• une classe pour les tokens générés : CalculatriceLexerTokensType.java ;
• d'autres fichiers (.txt, .smap) nécessaires à l'analyse.

6-3-f. Exécution du projet▲

Le lexer et le parser générés doivent être maintenant exploités dans la classe principale pour effectuer le travail attendu (opérations arithmétiques). Pour notre exemple, c'est la classe principale Frame qui s'en chargera. En faisant abstraction du code graphique, voici la méthode qui fera appel aux analyseurs une fois l'expression saisie et que l'utilisateur aura cliqué sur le bouton « = ». Le code complet de notre calculatrice Antlr peut être téléchargé en cliquant sur le lien ci-dessous situé à l'entête.

programme principal: utilisation des analyseurs générés

Sélectionnez

int compute(String expression){
       int result =0;
       CalculatriceLexer lexer = new  CalculatriceLexer(new StringReader(expression)); 
       CalculatriceParser parser = new CalculatriceParser(lexer);
        try {
                    parser.expr();
                                    
                        result = parser.resultat;
                       }   catch(Exception e) 
                       {
                             System.out.println("Erreur de saisie"); 
                       }
                    
     return result;