Automatiser le développement d'applications
parcours découverte avec CodeWorker

Date de publication : 24/09/2004

Date de mise a jour : 11/10/2004

Par Cédric Lemaire
 

Cet article expose une approche intéressante pour automatiser les tâches dans le développement d'applications, et procède au travers de quelques petits exemples concrets réalisés avec CodeWorker, un outil de parsing et un générateur de code polyvalents.

Introduction
1 CodeWorker et son langage de script
1.1 Installation
1.2 Généralités sur le langage
1.2.1 Quelques options de la ligne de commande
1.2.2 Les types de données
1.2.3 L'assignation
1.2.4 Les fonctions et procédures
1.2.4.1 Les fonctions/procédures prédéfinies
1.2.4.2 Les fonctions définies par le développeur
1.2.5 Les expressions
1.2.6 Les structures de contrôle
1.2.6.1 L'instruction foreach
1.2.6.2 L'instruction switch
2 L'analyse syntaxique
2.1 Vocabulaire
2.2 Exécution des règles de production
2.3 Extensions utiles de la BNF
2.3.1 La directive '#ignore'
2.3.2 L'opérateur '!'
2.3.3 La directive '#empty' et l'opérateur d'échappement '=>'
2.3.4 La directive '#continue'
2.3.5 L'opérateur '~'
2.3.6 L'opérateur de saut '->'
2.3.7 Récupération du texte lu dans des variables
2.3.8 Transmission de paramètres
2.3.9 Imposer la valeur lue par un symbole BNF
2.3.10 Les règles de production génériques
2.3.11 Quelques directives pseudo-terminales intéressantes
2.3.12 Remplissage du graphe de parsing
2.4 Exemple d'application : le videostore
3 Les modèles de génération de code
3.1 La génération de code classique
3.1.1 Exécution d'un modèle de génération
3.1.2 Les zônes de code protégées
3.1.3 La rupture de séquence
3.2 L'expansion de code
3.2.1 Injection de code sur les marqueurs
3.2.2 Script rattaché au marqueur
3.2.3 Affectation de données au marqueur
3.3 Exemple d'application : le videostore
4 La transformation de code
4.1 La conversion de code
4.2 La transformation de programme
Conclusion

L'automatisation du processus de développement d'applications concerne tout autant le développeur isolé qu'une équipe complète. Seul sur un projet d'envergure, le programmeur gagnera à automatiser la saisie du code rébarbatif et répétitif, pour se concentrer sur les facettes réellement importantes et intéressantes de l'application. Une équipe de développement prendra avantage à générer la charpente de ses applications, ainsi que la glue qui les relie à l'architecture, et capitaliser ses compétences techniques dans les modèles de génération.

La génération de code est le principal acteur qui conduit à augmenter la productivité et à améliorer la qualité du code source. En réduisant la saisie manuelle du code, vous réduisez le risque d'erreurs et leur dissémination par copier-coller. En laissant la machine générer du code pour vous, vous pouvez tester plusieurs variantes d'écriture de votre code, plusieurs techniques de programmation, plusieurs types d'architecture en un temps record. Vous donnez vie aux modèles de conception réutilisables (les fameux design patterns) et vous avez les moyens de créer les vôtres sans limite fixée à l'imagination.

Il n'y a cependant pas de génération de code sans information utile. Cette information utile représente vos spécifications, la description de l'univers métier. Elle alimente le générateur de code, mais n'en fait pas partie. C'est ainsi qu'un même générateur peut vous aider à écrire une application destinée à un magasin de jouets et une autre destinée à une usine de fabrication de chaussures. Malheureusement, il n'existe pas de format universel, ni même de syntaxe idéale, pour décrire des spécifications formelles. Et parfois même, ce format vous est imposé. Les spécifications peuvent provenir de diagrammes UML, d'un schéma SQL, d'un sous-ensemble de fichiers source, ... mais aussi de fichiers dont vous avez inventé le format, car il se prêtait parfaitement à la présentation de toute l'information utile spécifique à votre domaine.

On arrive ainsi au second intervenant dans l'automatisation des tâches de programmation, celui chargé d'extraire l'information utile quelle qu'en soit la source, et de la mettre à disposition du générateur de code.
Ce travail est rempli par un outil d'analyse syntaxique, chargé de ne récupérer que l'information utile à partir d'un format qu'on lui a appris à reconnaître. On l'appellera outil de parsing par la suite.

Combinez un outil de parsing et un générateur de code universel, et vous voilà secondé d'un collaborateur malléable et corvéable à merci, qui a l'avantage de produire des dizaines de milliers de lignes en quelques secondes, dans le respect de vos normes de programmation, et en conformité avec les choix techniques que vous vous êtes imposés. Il est très agile et ne rechigne pas devant les tâches à accomplir : changez vos spécifications, réarrangez la manière dont vous souhaitez voir le code écrit, et voici le résultat quelques secondes plus tard.

L'automatisation du processus de développement est un domaine très vaste, qu'étudie la programmation générative entre autre. Ici, nous nous contenterons d'aborder le sujet par le biais de quelques exemples fragmentaires, mais suffisamment illustratifs pour donner une idée de son champ d'application. Ils seront concrètement mis en oeuvre avec CodeWorker, un outil de parsing et de génération de code universel. C'est un Logiciel Libre disponible sous licence LGPL à l'adresse http://www.codeworker.org.

CodeWorker fonctionne en ligne de commande. Il interprète un langage de script, dont la syntaxe diffère selon qu'il s'agit d'écrire l'analyseur syntaxique ou les modèles de génération de code.

L'application se télécharge à partir de la page http://www.codeworker.org/Download.html. Une forme binaire est disponible pour la plateforme MS Windows, et parfois pour Mac OS X 10.3. Pour les autres plateformes, les sources sont mis à disposition, et compilent à l'aide d'un simple make all.

Sous Windows, vous aurez peut-être à télécharger les DLLs runtime de Visual C++ 7.1 msvcp71.dll et msvcr71.dll, disponibles sur la page de download du site. Vous vous en apercevrez en voyant surgir un message d'erreur explicite de la part du système. Dans ce cas, placez les DLLs dans le répertoire où se situe l'exécutable.

La documentation existe au format HTML, accessible en ligne à l'adresse http://www.codeworker.org/Documentation.html.
Sa version PDF se télécharge à l'adresse http://www.codeworker.org/CodeWorker.pdf.

Si vous souffrez de lenteurs d'accès au site de CodeWorker, vous pouvez choisir de télécharger la dernière version de l'outil ou de consulter la documentation, à partir de Developpez.com :

Téléchargement de la version de CodeWorker hébergée sur Developpez.com
Binaire pour les plateformes Windows	CodeWorker/CodeWorker_WIN3_8_2.zip
Sources pour toutes les plateformes	CodeWorker/CodeWorker_SRC3_8_2.zip
Documentation en ligne	CodeWorker/ScriptLanguage.html
Documentation PDF	CodeWorker/CodeWorker.pdf

Il existe trois grandes familles de scripts dans CodeWorker, et on dispose d'une extension de fichiers pour chacune d'elles.

• les scripts d'enchainement ou de liaison (ni parsing BNF, ni génération de code); extension en ".cws",
• les scripts de parsing BNF; extension en ".cwp",
• les scripts de génération de code; extension en ".cwt", le t final pour template-based script en anglais,

On pourrait citer une quatrième grande famille, celle des scripts de transformation, qui mêlent à la fois parsing BNF et génération de code. Cependant, ils s'apparentent à un script de parsing, simplement étendu de fragments de scripts de génération de code. Ils profitent donc de la même extension que celle d'un script de parsing BNF.

La ligne de commande diffère pour chacune des familles de scripts abordées précédemment.

• exécution d'un script d'enchainement monScript.cws :
  codeworker monScript.cws
  alternative vieillote :
  codeworker -script monScript.cws
• exécution d'un script de parsing BNF monScript.cwp sur un fichier monTexteAParser.txt :
  codeworker -parsebnf monScript.cwp monTexteAParser.txt
• exécution d'un script de génération de code monScript.cwt sur un fichier monTexteAGenerer.txt.
  
  • Génération classique :
    codeworker -generate monScript.cwt monTexteAGenerer.txt
  • Expansion de code (génération à certains points du fichier) :
    codeworker -expand monScript.cwt monTexteAGenerer.txt
  • Auto expansion de code. Ici, le(s) script(s) de génération de code est(sont) incrusté(s) dans le fichier texte :
    codeworker -autoexpand monTexteAGenerer.txt
• exécution d'un script de transformation de code monScript.cwp, avec lecture d'un fichier monTexteAParser.txt et écriture dans un fichier monTexteAGenerer.txt. Si les deux fichiers sont les mêmes, il s'agit d'une transformation. S'ils sont différents, on parle de traduction.
  codeworker -translate monScript.cwp monTexteAParser.txt monTexteAGenerer.txt

Voici comment exécuter un script selon sa nature. D'autres options de la ligne de commande se révèlent indispensables à l'usage.

Nous citerons tout d'abord l'option -I suivie d'un chemin de répertoires (-I chemin), qui informe l'interpréteur de tous les chemins où il est susceptible de trouver les fichiers de scripts nécessaires au projet.

Vient ensuite l'option -D suivie d'un identifiant (-D identifiant) et, éventuellement, d'une valeur (-D identifiant=valeur); si valeur il y a, et qu'elle contient des espaces, celle-ci doit se placer entre guillemets. L'identifiant s'appelle une propriété, et sa valeur peut être interrogée dans les scripts par la fonction getProperty("identifiant").

On peut terminer sur l'option -c++, dont le rôle est de traduire tous les scripts du projet en C++, pour construire un exécutable et se passer de l'interpréteur. Le premier paramètre attendu est le chemin où générer les fichiers C++ correspondant aux scripts, et le second est le chemin qui mène aux quelques entêtes de fichiers C++ CodeWorker appelés dans les sources générés.

Il existe de nombreuses autres options proposées sur la ligne de commande. Pour obtenir un aperçu, tapez :
codeworker -help

CodeWorker manipule un type unique de structure de données, qui offre la possibilité de stocker une valeur, une référence sur une autre donnée, une liste d'éléments (ou, plus généralement, une table d'association) et une structure d'arbre.
Une donnée peut représenter tout cela à la fois.

Il existe une variable globale appelée project, toujours présente et accessible de tous les scripts.
Cette variable est souvent utilisée pour y stocker les informations utiles lors du parsing et les transmettre à la génération de code, mais ce n'est pas une obligation car on peut à tout moment déclarer une variable locale.
La particularité d'une variable locale est d'être placée sur la pile de l'application, ce qui contraint sa durée de vie au temps passé dans le bloc d'instructions où elle a été déclarée. Une fois sortie du bloc d'instructions, la variable locale est détruite.

Le type unique de structure de données

Une valeur peut se révéler un nombre entier ou flottant, un booléen ou une chaîne de caractères. A propos des valeurs booléennes, il faut savoir que le faux se représente par une chaîne de caractères vide (mot-clé false), et qu'un nombre ou toute chaîne de caractères non vide signifie vrai ; dans ce dernier cas, on peut cependant utiliser la constante true (qui vaut la chaîne de caractères "true") pour forcer à vrai. Exemples: local nombre = 25.7; local chaine = "vingt cinq virgule sept"; local booleen = (nombre == chaine); Une table d'association se présente comme un tableau, qui a la particularité d'être non pas forcément indicé par un entier, mais par n'importe quel type de valeur. Dans CodeWorker, les tables d'association sont indicées par des nombres (entiers ou flottants) ou par des chaînes de caractères, que l'on appelle la clé ou l'entrée dans la table. Exemple : local dictionnaire; insert dictionnaire["sardine"] = "Petit poisson marinant dans l'huile"; insert dictionnaire[3.141592] = "Premiers chiffres de Pi"; On peut développer un arbre à partir de n'importe quelle variable. La branche qui mène à un noeud fils est nommée par un identifiant (séquence de caractères alphanumériques, dont le premier n'est pas un chiffre), que l'on appelle aussi l'attribut. Exemple : local jouet; insert jouet.categorie = "voiture"; insert jouet.alimentation = "piles"; insert jouet.alimentation.quantite = 4; insert jouet.alimentation.taille = "LR6"; On remarque ici l'analogie entre la structure d'arbre et celles plus classique de structure C ou de classe C++/Java sans héritage. On appelle d'ailleurs categorie un attribut de jouet.

Au cours des exemples de la section précédente, nous avons découvert deux mot-clés.

Le premier, local, sert à déclarer une variable locale, dont la portée est celle du bloc d'instructions dans laquelle elle est apparue. On remarque dans le premier des exemples ci-dessus, que l'on peut assigner une valeur dans la foulée.

Le second, insert, annonce une assignation de valeur avec création de l'élément ou du noeud qui reçoit la valeur. Si le noeud existe déjà, la création est bien sûr ignorée et l'assignation se déroule normalement.

Si vous omettez le mot-clé insert lors de l'assignation à un attribut ou à un élément non encore existant, un avertissement est produit par l'interpréteur, ceci afin de pallier l'absence de typage fort dans le langage. En effet, pour une variable sensée exister, vous n'utiliserez pas le mot-clé insert pour opérer l'assignation. Et si vous avez introduit une faute de frappe quelque part dans son nom, celle-ci ne sera pas trouvée par l'interpréteur qui vous avertira.

Il faut bien noter que l'assignation vue jusqu'à présent ne copie qu'une valeur. Si vous voulez recopier une donnée complète, c'est-à-dire avec sa valeur, son arbre et sa table d'association, il faut utiliser setall en tête de l'instruction d'affectation.

Exemple :

Lorsqu'une copie complète est requise avec setall, la variable assignée est préalablement purgée :
plus de valeur, plus de table d'association, plus de graphe. Dans certains cas, on peut vouloir simplement fusionner cette variable avec une autre. Dans cette opération de fusion, les attributs ou éléments de tables d'association qui n'existent pas dans la variable à fusionner, sont simplement copiés. Ceux qui n'ont pas la même valeur sont modifiés. L'opération de fusion d'une variable dans une autre s'accomplit en introduisant le mot-clé merge en tête de l'instruction d'assignation.

Exemple :

Il peut arriver qu'une variable doivent faire référence à une donnée, de telle sorte que lorsqu'on manipule le référant, ce soit propagé sur le référé. C'est l'instruction ref qui se charge d'établir la référence.

Exemple :

La syntaxe d'un appel de fonction est similaire à celle des langages de la famille du C, à savoir un identifiant suivi d'arguments séparés par des virgules, et placées entre parenthèses. L'identifiant est le nom de la fonction. Une procédure est une fonction qui ne renvoie pas de paramètres.

Exemples :

Le seul type de retour autorisé pour une fonction est un type de base : chaîne de caractères, entier, booléen, nombre flottant. En aucun cas une fonction ne retournera une référence sur une variable, un graphe ou une table d'association. Si cela s'avérait malgré tout nécessaire, le paramètre de retour devra figurer comme argument de la fonction, passé par référence (mode by node).

Si le premier paramètre d'une fonction ou d'une procédure est une variable, il existe une écriture pseudo-appel de méthode qui apporte parfois plus de clarté à la lecture du script :

CodeWorker propose un certain nombre de fonctions et procédures prédéfinies, dans des domaines aussi variés que la manipulation des chaînes de caractères, des nombres ou des dates, la gestion de fichiers et de répertoires, la manipulation des noeuds d'un graphe, celle des éléments d'un tableau, quelques commandes système...
Elles sont toutes recensées par catégorie sur le site de CodeWorker à l'adresse http://www.codeworker.org/Documentation.html.

Deux procédures nous serons particulièrement utiles par la suite : traceLine() et traceObject(). La première écrit une ligne de texte dans la console, tandis que la seconde décrit la structure de premier niveau d'une variable : sa valeur, ses attributs directs (avec leur valeur et les clés de leur table d'association éventuelle) et sa table d'association.
Ces deux procédures sont très utiles à des fins de trace ou d'exploration du contenu d'une variable.

Pour faire bonne mesure, introduisons la procédure saveProject(). Elle se charge de sauver au format XML la structure complète de la variable project, dont nous avons déjà parlé plus haut. Si vous avez pris soin d'alimenter cette variable avec toute l'information utile, le fichier XML sera son reflet exact, et facilitera par là-même la mise au point de vos scripts.

Le programmeur peut implanter ses propres fonctions. L'implantation d'une fonction est annoncée par le mot-cle function.
Les paramètres sont passés soit par valeur (mode par défaut), soit par référence. Le corps de la fonction est placé entre accolades. Une fonction ne peut retourner qu'une valeur, à l'exclusion de tout autre type (graphe, table d'association, référence sur une variable). Pour ce faire, on se sert du mot-clé return, éventuellement suivi d'une expression. Une fonction qui ne retourne pas de valeur rend toujours une chaîne vide.

Exemple :

Par défaut, les expressions s'appliquent aux chaînes de caractères, et non pas aux nombres. Les constantes numériques sont traduites en écriture base 10 sous la forme d'une séquence de caractères, donc toutes les valeurs sont manipulées comme des chaînes de caractères. L'opérateur + sert par exemple à concaténer les chaînes et non pas à sommer des nombres.

Les opérateurs de comparaison travaillent eux-aussi sur les chaînes. Ainsi, (2 < 10) échoue car, en réalité, c'est la comparaison ("2" < "10") des chaînes de caractère correspondantes qui est réalisée.

Dans un contexte d'analyse syntaxique et de génération de code, il est rarissime d'avoir besoin de calculer sur des nombres, puisque soit l'un, soit l'autre, ont pour tâche de manipuler du texte. C'est pourquoi ce n'est absolument pas vécu comme une contrainte d'exécuter les expressions sur les chaînes. Cependant, pour les cas où il reste indispensable de résoudre des expressions sur les nombres, il existe un moyen pour basculer en mode "résolution d'expressions arithmétiques" : il suffit de placer l'expression entre symboles '$'. Ainsi, la comparaison $2 < 10$ devient vraie, et $2 + 10$ donne 12 et non pas "210".

Comme la plupart des langages, CodeWorker admet un certain nombre de structures de contrôle. Nous avons eu l'occasion de croiser l'instruction if au sein d'un précédent exemple. Il existe aussi le while et le do... while. Tous ressemblent beaucoup à leurs cousins C, C++ et Java, à la différence près qu'il n'est pas imposé de mettre les conditions entre parenthèses.

Il existe encore d'autres structures de contrôle, mais seuls le foreach et le switch seront abordés dans la suite de cette section.

L'instruction foreach sert à itérer les éléments d'une table d'association. Un index pointe sur l'élément courant de la table d'association. Il y a trois fonctions qui ne peuvent s'appliquer que sur les indices de boucle.
La première, key(), permet d'obtenir la clé associée à l'élément courant de la table d'association.
La seconde, first(), retourne vrai si l'index pointe sur le premier élément parcouru de la table.
La troisième, last(), retourne vrai si l'index pointe sur le dernier élément parcouru de la table.

Exemple :

donne à la console :

L'instruction switch a ceci de particulier qu'elle aiguille sur des chaînes de caractères, contrairement à sa congénère C, C++ ou Java, qui aiguille sur des numéraires. Pour ceux qui ne sont pas familiers avec comportement de cette commande, rappelons qu'elle permet de sauter directement à un certain bloc d'instructions (parmi plusieurs proposés), conditionnellement à la valeur prise par une expression donnée. Pour le reste, vous en apprendrez plus par l'exemple.

Exemple :

Si l'on omet le default et qu'une valeur n'est reconnue par aucun des cas du switch, une erreur sera remontée à l'exécution.
On aura remarqué une originalité : start est un cas qui prend toutes les valeurs commençant par une portion de texte bien définie.

Pour l'accomplissement des tâches d'analyse syntaxique, CodeWorker s'inspire de la notation utilisée pour décrire les grammaires formelles, appelée Backus-Naur Form, ou BNF pour les initiés. Dans l'outil, cette notation a été bien étendue pour rendre l'écriture des scripts de parsing la plus efficace possible.

Partons d'un exemple de script pour découvrir quelques concepts :

Nous avons décrit là trois règles de production.
La première définit ce qu'est un entier : une séquence de chiffres décimaux, éventuellement précédée d'un signe négatif.
La deuxième précise comment écrire un nombre flottant : parties entière et fractionnaire séparées par un point (notation anglo-saxonne), et éventuellement un exposant. Ici, pour ne pas alourdir la grammaire mais surtout afin d'introduire plus bas un opérateur spécial, nous restons laxistes et nous autorisons temporairement la partie fractionnaire à être négative.
La troisième prétend qu'un nombre est soit un flottant, soit un entier.

A présent, un peu de terminologie : les règles de production sont composées d'une séquence de symboles BNF (entier '.' entier ['e' entier]? par exemple), ou d'alternatives parmi des séquences de symboles BNF (flottant | entier offre deux alternatives : soit la séquence BNF entier, soit la séquence BNF flottant).

Un symbole BNF est dit terminal s'il se limite à une constante ('-' et 'e') ou à un intervalle de constantes ('0'..'9').
Un symbole BNF est dit non-terminal s'il conduit à appeler une autre règle de production (dans la séquence entier '.' entier ['e' entier]?, entier est un symbole non-terminal).
Pour les puristes, par abus de langage mais pour simplifier le discours, on considère aussi la répétition d'une séquence BNF (ou d'alternatives sur séquences BNF) comme un symbole BNF.

Nous avons ci-dessus l'illustration de deux types de répétition. On peut recenser cinq formes communes :

• apparition optionnelle d'une séquence (ou d'alternatives) : ['-']? signifie que le signe '-' peut ne pas être présent,
• apparition au moins une fois : ['0'..'9']+ signifie qu'on attend une suite non vide de chiffres décimaux,
• absence ou apparition multiple : ['A'..'Z']* signifie qu'on attend un mot en majuscule ou sinon, autre chose qu'une lettre majuscule,
• répétition un nombre fixé de fois : ['#']4 signifie qu'on attend 4 dièses les uns derrière les autres,
• répétition un nombre de fois compris dans un intervalle : ['#']4,6 signifie qu'on attend entre 4 et 6 dièses les uns derrière les autres,

La règle de production en tête de gammaire est son point d'entrée. Elle sera exécutée par le moteur BNF de l'interpréteur. Cette exécution amènera à rencontrer des symboles non-terminaux dans la règle, symboles qui, à leur tour, appelleront leur règle de production attachée.

Exemple :
Une grammaire sensée lire un nombre commencera par décrire ce qu'est un nombre. Retouchons notre exemple initial pour que la règle de production d'un nombre se retrouve en tête de grammaire :

Le reste de cette section vous paraîtra peut-être un peu ardu. Si c'est le cas, n'insistez pas et sautez à la prochaine section. Vous y reviendrez plus facilement après avoir vu fonctionner les scripts de parsing.

Les règles de production parcourent un texte de la gauche vers la droite, et leurs symboles BNF s'appliquent le plus à gauche possible (on tente de satisfaire d'abord le premier symbole de la séquence, puis on passe au suivant). Lorsqu'une séquence BNF échoue, on essaie la prochaine alternative. S'il ne reste plus d'alternatives, on quitte la règle de production en échec, ce qui fait échouer le symbole non-terminal qui l'a appelé. A son tour, le symbole non-terminal provoque l'échec de la séquence BNF à laquelle il appartient, et on continue ainsi.

A procéder de la sorte, ce type de parseur est dit à descente récursive et même, plus précisément, LL(k). Le premier L est là pour rappeler un parcours de la gauche (Left) vers la droite, le second pour signifier qu'on résoud la règle le plus à gauche possible (Left-most), et le petit k pour dire qu'il peut anticiper plusieurs coups d'avance (nombre indéterminé k) avant de résoudre une ambiguïté.

CodeWorker ne résoud pas automatiquement une ambiguïté; il faut parfois arranger les règles de production. Pour illustrer ce que l'on entend pas là, reprenons l'exemple en tête de section. Un nombre est soit un flottant, soit un entier. Or, un nombre flottant commence toujours par un entier dans notre définition. Donc, si l'on inverse maintenant la règle de production :

Nous avons déjà rencontré une extension de la notation Backus-Naur; il s'agit de la répétition (['0'..'9']+ par exemple) et du caractère facultatif d'une séquence de symboles BNF ((['-']? par exemple)). Ils ne sont pas indispensables et peuvent s'exprimer uniquement à l'aide de symboles terminaux et non-terminaux, mariés à l'alternative. En revanche, pour une exploitation concrète efficace, il serait laborieux de ne pas disposer de ces raccourcis pour désigner répétition et optionnalité.

Nous allons découvrir d'autres extensions de la BNF, en prenant appui sur l'exemple des sections précédentes que nous enrichissons de quelques règles de production.

Exemple :
On veut disposer d'une grammaire qui lit un fichier composé d'une suite de nombres et d'identifiants. Un identifiant commence par une lettre ou un underscore, et poursuit par une séquence de lettres, d'underscores et de chiffres.

Dans le fichier texte à lire, ces nombres et identifiants sont séparés par des caractères blancs, genre espaces, tabulations et retour-chariots. Malheureusement, notre grammaire n'ignore pas ces caractères entre ces symboles non-terminaux.

Le moment est venu d'introduire la directive #ignore(blanks). Cette directive stipule que, dorénavant, avant chaque symbole de la séquence BNF à laquelle elle appartient, les caractères blancs seront ignorés automatiquement par le moteur BNF. La règle de tête devient alors :

Seulement voilà! L'ignorance des caractères insignifiants se propage dans les règles de production appelées par les symboles non-terminaux nombre et identifiant, et ainsi de suite. Conséquence : on ignore aussi les espaces entre les chiffres d'un entier et les lettres d'un identifiant. Or, c'est erroné : un entier est une série de chiffres contigus, collés les uns aux autres.

Il faut donc débrayer localement l'action d'ignorer les blancs au niveau de la définition d'un entier, d'un flottant et d'un identifiant. C'est le rôle de la directive #!ignore. On retouche donc les trois règles :

A présent, corrigeons la règle de production du nombre flottant, où nous avions volontairement autorisé la partie fractionnaire à être négative. Il existe un opérateur spécial, noté !symbole-BNF, qui échoue si le symbole BNF sur lequel il porte est valide, et qui réussit en cas d'échec du symbole BNF. Dans les deux cas, la règle de production ne progresse absolument pas dans sa lecture. Si l'on emploie une seconde fois cet opérateur (!!symbole-BNF), il signifie évidemment qu'il réussit si le symbole BNF réussit, et qu'il échoue si le symbole BNF échoue, MAIS sans jamais progresser dans la lecture. Avantage : cela permet d'accomplir une lecture anticipée (look ahead en anglais) du texte sans déplacer le curseur de lecture.
A présent, employons l'opérateur ! avant de lire la partie fractionnaire, pour nous assurer que cette partie fractionnaire n'est pas négative :

Nous avançons, mais nous n'avons pas encore le moyen de nous assurer que le texte se conforme à la grammaire. En effet, si la grammaire n'arrive pas à s'appliquer sur le fichier texte, l'analyse s'achève en silence.

La directive #empty s'assure que la fin du texte a été atteinte. Ce symbole terminal échoue dans le cas contraire. Voici donc la première partie : nous sommes capable de détecter la fin du texte à lire, mais pas encore d'avertir l'utilisateur que tout s'est bien passé. Supposons que nous voulions tracer un message dans la console : nous avons besoin d'insérer un bout de script chargé d'écrire le message. L'insertion d'un bout de script s'annonce par l'opérateur => et est suivie par une instruction terminée par un point-virgule ou suivie par un bloc d'instructions fiché entre accolades. Lorsque le moteur de résolution BNF rencontre ce symbole, il comprend qu'il s'agit là d'une instruction qui ne le concerne pas, et demande son interprétation au moteur de script standard.

Voici ce que devient alors notre règle de tête :

Si l'analyse aboutit, un message apparaîtra. Mais si elle échoue, comment savoir où cela s'est produit, à quelle ligne, quelle colonne, pour quelle raison? Pour répondre à toutes ces questions, introduisons la directive #continue. Placée dans une séquence de symboles BNF, elle impose que le reste de la séquence aboutisse.
Si un symbole BNF venait à échouer dans la séquence, un message d'erreur serait remontée automatiquement, signalant la ligne et la colonne fautive, ainsi que le symbole BNF en faute.

Exemple :
Dans la règle de production d'un nombre flottant, si l'on arrive à lire un entier suivi d'un point, l'on a la certitude de se trouver face à un flottant. Le contraire rèvèlerait une erreur de syntaxe. Il en va de même avec l'exposant : la lettre 'e' annonce un exposant entier.

Ainsi, si la partie fractionnaire n'est pas composée d'un entier positif, ou si l'exposant n'est pas suivi d'un entier, une erreur de syntaxe est produite, grace au placement que l'on a fait de la directive #continue. Il en est de même si l'on n'arrive pas à atteindre la fin de fichier.

L'avantage que l'on peut tirer de l'usage du #continue est de deux natures symétriques. Durant la phase de mise au point, si vous êtes sûr du fichier texte que vous utilisez pour les tests, si une erreur est remontée, cela signifie que vous vous êtes trompé dans l'écriture de la grammaire. Durant la phase de production, si vous êtes confiant dans votre grammaire, cela signifie que le fichier texte lu comporte une erreur de syntaxe. Dans les deux cas, la correction s'avère très rapide en général, car la pile d'appel des non-terminaux est remontée avec le message d'erreur.

Enrichissons notre grammaire afin d'accepter les chaînes de caractères entre guillemets.

L'on a introduit un nouvel opérateur, qui s'écrit ~symbole-BNF. Il est valide et avance de une position dans la lecture du fichier texte si le symbole BNF échoue. Il échoue et reste sur place si le symbole BNF réussit.
Dans la règle de production, employé avec la répétition multiple, il signifie que l'on avance d'un cran tant que le guillement final n'a pas été atteint.

Il est très fréquent d'utiliser conjointement l'opérateur de négation, que nous venons de découvrir, avec la répétition multiple et la consommation du symbole BNF à atteindre : [~'"']* '"' dans l'exemple précédent, qui signifie d'avancer jusqu'à trouver le guillement, puis le consommer, c'est-à-dire le parcourir. On peut l'exprimer différemment :
sauter juste après le premier guillement rencontré.

Cette opération de saut peut s'écrire ->symbole-BNF, et est la forme condensée de [~symbole-BNF]* symbole-BNF. On peut réécrire la règle de production d'une chaine :

Pour l'instant, notre analyse syntaxique s'est bornée à scanner le fichier texte, et n'a pas cherché à extraire l'information utile. Pour récupérer la partie du texte parcourue par un symbole BNF, il suffit de rajouter le nom de la variable à assigner, derrière le symbole et après les avoir séparé par un deux-points.

Exemple :

Les variables iExposant et sChaine n'ont pas été déclarées préalablement. Elles sont donc créées automatiquement sur la pile. iExposant a seulement la portée des crochets dans lesquels elle a été déclarée : elle n'est plus visible une fois sorti de l'optionnalité. En revanche, sChaine a la protée de la règle de production.

Pour la lecture de l'exposant, tout va bien : on a bien la valeur de l'entier. En revanche, il y a un petit souci pour la chaîne de catactères : l'opérateur de saut lit jusqu'au guillement terminal, que l'on retrouve donc dans la variable sChaine, alors qu'on ne désirait que le texte inclus entre les guillements. On voudrait réclamer de ne récupérer que le texte lu jusqu'avant la consommation du guillement terminal. C'est possible en précisant la variable, précédée de deux-points et encadrée de parenthèses, entre la flêche et le symbole BNF sur lequel sauter.

Ce n'est pas encore parfait, car si la règle de tête récupère dans une variable le texte parcouru par le non-terminal chaine, elle se retrouvera en présence des guillemets initiaux et finaux. Heureusement, on peut construire soi-même la valeur que doit retourner une règle de production. Le nom de la règle doit être suivi de value après deux-points, et la valeur doit être affectée à une variable qui a le nom de la règle.

Nous savons maintenant récupérer localement des fragments de texte, ceux qui nous paraissent pertinents. Il ne nous reste plus qu'à les ranger dans une structure de données. Voyons comment procéder à partir de notre exemple, que nous allons retravailler.

On considère nos fichiers texte comme une suite d'éléments. Un élément est soit un nombre, soit un identifiant, soit une chaîne. On veut ranger dans une liste la séquence d'éléments que nous avons extraites.

Epluchons à présent cet exemple. Lorsqu'un script BNF s'exécute, il ne voit pas le scope des variables du script qui l'a lancé. Notamment, il ne sait pas quelle variable renseigner avec les fagments de texte qu'il aura extraits du fichier.
C'est pourquoi, chaque fois qu'on lance un script de parsing BNF, avec la procédure parseAsBNF(script, variable, fichier_texte), on lui passe le nom de la variable à renseigner. C'est le deuxième paramètre de la procédure. A l'intérieur du script de parsing BNF, cette variable s'appelle this dans tous les cas, et représente le contexte que l'appelant a bien voulu lui soumettre.

Nous voulons renseigner la variable this avec une liste d'éléments. La directive #pushItem(liste) rajoute un élement dans la liste passée en paramètre : dans la table d'association, un nouvel élément est inséré avec un indice entier comme valeur de la clé. L'indice commence à compter à partir de zéro, et s'incrémente. Si la séquence BNF à laquelle appartient la directive échoue, l'élément est automatiquement supprimé de la liste.

La règle de production element se charge de remplir ce nouvel élément de la liste. Pour ce faire, il est passé en paramètre à la règle de production, qui attend un argument passé par référence (le mode de passage par référence est node, comme pour les fonctions).

Supposons à présent que nous voulions écrire une grammaire capable de lire la description de jouets et de desserts du genre :

• chaque jouet appartient à une catégorie et détaille son alimentation (type, taille, quantité),
• chaque dessert appartient à une famille, utilise un type de pate et a une garniture simple ou multiple,

Voici un exemple de fichier texte qui respecte cette grammaire :

Vu l'état actuel de nos connaissances sur CodeWorker, on écrirait notre grammaire ainsi :

Cette grammaire ne décrit pas tout à fait ce que nous voulons. En effet, elle n'est pas capable de tétecter une erreur de syntaxe si le fichier texte ne comprend pas de blancs entre jouet et categorie, que les deux mots soient attachés pour former jouetcategorie. Il aurait fallu écrire que l'on voulait lire un identifiant valant valant jouet exactement. Cela se note identifiant:"jouet".

Supposons à présent que la taille des piles soit à prendre parmi LR3, LR4 et LR6, et que l'on veuille la récupérer dans une variable. On écrit cela ainsi : chaine:{"LR3", "LR4", "LR6"}:sTaille.

La règle de production intègre maintenant ces deux ajustements :

On s'aperçoit alors que les attributs taille et quantite n'ont un sens que si l'alimentation du jouet se fait par piles. Il existe la directive #check(expression), qui réussit si l'expression booléenne est valide, et qui échoue dans le cas contraire.

Supposons à présent qu'il soit fréquent d'enrichir ce format de nouveaux attributs, et parfois même, de nouveaux objets. Il peut devenir difficile de maintenir la grammaire à jour. Heureusement, il existe un moyen de détecter lorsque la grammaire tombe sur un attribut qu'elle ne sait pas encore traiter. Cela se fait grâce aux règles de production génériques instantiées, dont voici un exemple :