Les regex et grammaires de Perl 6

Pour rechercher dans un répertoire tous les fichiers dont le nom commence par la lettre «a» et dont l'extension est .txt, on peut écrire à l'invite du système :

ls  a*.txt    # shell Unix, Linux, etc.
# ou :
dir a*.txt    # console DOS/cmd ou Powershell Windows, VMS, etc.

Le nom de la commande employée (ls ou dir) diffère selon le système d'exploitation, mais le motif employé se trouve être ici le même : a*.txt. Il signifie plus précisément quelque chose du genre : lettre «a», suivie d'un nombre quelconque de caractères quelconques, suivis de la chaîne de caractères «.txt».

La commande employée affichera à l'écran tous les fichiers du répertoire courant dont le nom respecte le motif a*.txt. Cette façon de filtrer les noms des fichiers du répertoire (ou dossier en terminologie Dos/Windows) avec un motif est le principe de fonctionnement des expressions régulières : le motif décrit, généralement de gauche à droite, une série d'éléments que l'on doit rencontrer dans la chaîne de caractères cible (ici le nom de fichier) : d'abord la lettre « a », puis des caractères quelconques, puis la chaîne «.txt».

L'analogie s'arrête là, car la syntaxe des expressions régulières communément employées dans les langages de programmation donne un sens différent au métacaractère «*» (voir § 2.4.).

Les premières utilisations d'expressions régulières en informatique ont été mises en œuvre dans les années 1970 par Ken Thompson, l'un des créateurs du système Unix, dans les éditeurs qed et ed (qui ne sont plus guère employés) et dans la commande Unix grep, encore très utilisée de nos jours.

Par exemple, sous Unix ou Linux, la commande grep suivante permet d'afficher toutes les lignes du fichier texte.txt qui contiennent les lettres «ab», suivies d'un caractère quelconque, suivies de la lettre «d» :

$> grep ab.d texte.txt

Dans le motif ab.d, le métacaractère «.» signifie « un seul caractère quelconque », si bien que la commande ci-dessus pourra par exemple afficher les lignes suivantes du fichier :

abcd
abvd ...
... abyd
... xyabcdz ...
xyab3dgh

D'autres utilitaires Unix encore très employés de nos jours et utilisant aussi les expressions régulières ont rapidement vu le jour : sed, vi, awk, lex, emacs, egrep, etc.

Le langage Perl (Perl 1 est apparu en décembre 1987) est sans doute le premier langage de programmation généraliste (hormis awk, qui n'est pas un langage généraliste et qui est assez particulier) à avoir intégré les expressions régulières, suivi plus tard par d'autres.

Très rapidement, Perl (en particulier Perl 5 depuis 1994) a considérablement étendu ses expressions régulières, au point qu'elles ont cessé depuis bien longtemps d'être « régulières » ou « rationnelles » au sens d'origine strict du terme, mais offrent en revanche un surcroît d'expressivité tel qu'elles ont fini par être copiées par bon nombre de langages de programmation tels que Tcl, Python, PHP, Ruby, .NET, Java, JavaScript, Delphi, etc. L'influence de Perl 5 sur ces langages est telle qu'ils utilisent pour la plupart une bibliothèque appelée « Perl Compatible Regular Expressions » (PCRE) : bref, pour attirer l'utilisateur, il fallait mettre en avant le fait que la solution proposée suivait la syntaxe des « expressions régulières étendues » de Perl.

Avec Perl 6, les expressions régulières utilisent toujours la même méthode générale de reconnaissance progressive de gauche à droite d'un motif, mais elles sont encore moins régulières (au sens strict des langages formels non contextuels d'origine) et encore plus puissantes que celles de Perl 5, si bien qu'il a été décidé d'abandonner le terme « expressions régulières » pour les désigner et de les nommer regex. L'ajout au fil du temps de nouvelles fonctionnalités avait fini par rendre la syntaxe des expressions régulières de Perl 5 quelque peu touffue, en grande partie parce que Perl 5 s'est toujours attaché à préserver dans toute la mesure du possible la rétrocompatibilité.

Perl 6 ayant décidé d'être un nouveau langage et d'abandonner cette exigence de rétrocompatibilité, cela a permis de refondre assez profondément le langage des regex, de l'élargir considérablement et de le rendre plus cohérent et plus logique.

De plus, de nombreux exemples ci-dessous montreront comment il est possible de construire des regex simples et de leur donner un nom afin de pouvoir ensuite les assembler comme s'il s'agissait des briques d'un jeu de construction pour former des motifs de recherche de plus en plus complexes. Par exemple, une adresse IP v4 se compose de quatre octets (généralement représentés par quatre nombres entiers compris, en notation décimale, entre 0 et 255, séparés par des points). Il est très facile en Perl 6 d'écrire une première regex, que l'on nommera par exemple octet et qui vérifiera que l'on a bien un nombre satisfaisant les conditions voulues, puis d'assembler une nouvelle regex reconnaissant quatre de ces octets, séparés par des points (voir § 4.2.4.).

Mais la véritable révolution apportée par les regex de Perl 6 est qu'elles permettent de construire des entités encore plus puissantes, les grammaires (voir § 3.). Une grammaire est un formalisme permettant de définir une syntaxe et, donc, un langage formel. En Perl 6, elle se présente sous la forme d'un groupe de règles et de regex nommées et permet de construire progressivement un système de reconnaissance de texte beaucoup moins bien structuré que ce que l'on peut reconnaître avec les expressions régulières (même étendues) de Perl 5. Une grammaire permet donc de procéder à l'analyse lexicale et syntaxique d'un texte, par exemple du code source d'un programme informatique en vue de le compiler. Perl 6 possède sa propre grammaire de Perl 6, écrite en Perl 6.

Les expressions régulières ont parfois la réputation d'être abstraites et difficiles à comprendre. Les expressions régulières sont construites par assemblage de concepts simples qui ne sont pas plus compliqués à comprendre que les conditions if et les boucles while ou for du langage Perl lui-même. En fait, le véritable enjeu dans l'apprentissage des expressions régulières réside dans la compréhension de la notation très concise, voire laconique, souvent utilisée pour exprimer ces concepts. En fait, Perl 6 permet de simplifier considérablement la compréhension des expressions régulières en offrant la possibilité d'insérer des espaces, des commentaires, etc. Il est toujours possible de continuer à écrire des regex très concises et parfois un peu difficiles à déchiffrer, et c'est parfois suffisant pour des problèmes simples, mais personne n'y est obligé. La différence est flagrante dans l'exemple du chapitre Formatage du code vers la fin de ce document.

Bien que ce ne soit pas réellement l'objet du présent tutoriel, il est utile de rappeler brièvement quelques opérateurs Perl 6 utilisant les regex.

En Perl 6, l'opérateur de base pour vérifier si une chaîne de caractères correspond à un motif est l'opérateur ~~ de reconnaissance intelligente (smart match operator). Par exemple :

say "Reconnu" if "abcdef" ~~ /ab.d/;    # -> Affiche : Reconnu

Ici, la chaîne de caractères à analyser est « abcdef » et le motif de la regex /ab.d/. Le motif est reconnu, parce que l'on peut faire une correspondance entre les quatre atomes du motif (le point «.»reconnaît un caractère quelconque, donc, ici, il reconnaît « c ») et une partie de la chaîne de caractères ; le motif décrit en quelque sorte cette partie de la chaîne. Bien sûr, le motif /ab.d/ aurait aussi reconnu, par exemple, les chaînes « abwdef », « ab7def » ou « suabZda ».

À noter que l'opérateur de reconnaissance intelligente ~~ utilisé ici pour lier une chaîne de caractères et un motif de regex sert à beaucoup d'autres choses en Perl 6 (par exemple vérifier la présence d'un élément dans un tableau, ou vérifier la compatibilité d'une variable avec un type, etc.), mais ce n'est pas l'objet du présent document (voir par exemple Opérateur de reconnaissance intelligente).

Si la chaîne de caractères à analyser est stockée dans la variable par défaut $_, alors la présence de l'opérateur de reconnaissance intelligente n'est pas nécessaire et la regex peut être évaluée directement en contexte booléen :

if / ^ab / {
    say "La chaîne $_ commence par les lettres 'ab'";
}

Il est possible d'utiliser la forme négative !~~ de l'opérateur de reconnaissance intelligente :

say "Chaîne 'ab' non trouvée" if "fedcba" !~~ /ab/; 
                                      # -> Chaîne 'ab' non-trouvée
# Équivalent à :
say "Chaîne 'ab' non trouvée" unless "fedcba" ~~ /ab/;

Perl 6 autorise également une syntaxe de méthode orientée objet avec la méthode .match :

say "Reconnu" if "abdcef".match(/c.f/);   # -> Reconnu

Les regex permettent également d'effectuer des substitutions :

my $chaîne = "abcde";
$chaîne ~~ s/bc/CB/;
say $chaîne;                              # -> affiche aCBde

Il existe également une méthode .subst permettant d'effectuer une substitution (mais pas « en place » comme le permet l'opérateur s///) :

my $chaîne = "abcde";
my $chaîne-modifiée = $chaîne.subst(/cd/, "DC");  # -> abDCe

Il est cependant possible de modifier directement la variable $chaîne (sans créer de nouvelle variable) en la plaçant également dans la partie gauche de l'affectation :

my $chaîne = "abcde";
$chaîne = $chaîne.subst(/cd/, "DC")      # -> abDCe

Le premier argument de la méthode .subst peut être soit une regex, soit une chaîne de caractères.

La fonction split et la méthode .split qui divisent une chaîne de caractères en une liste de sous-chaînes en fonction d'un motif de coupure, peuvent également utiliser soit une chaîne, soit une regex :

say split(';', "a;b;c,d").perl;        # ("a", "b", "c,d").Seq
say split(/\;/, "a;b;c,d").perl;       # ("a", "b", "c,d").Seq
say split(/<[;,]>/, "a;b;c,d").perl;   # ("a", "b", "c", "d").Seq
# Version syntaxe de méthode orientée objet :
say "a;b;c,d".split(/<[;,]>/).perl;    # ("a", "b", "c", "d").Seq

La fonction comb et la méthode .comb renvoient une liste de reconnaissances (gourmandes) d'un motif sur une chaîne :

say join " ", comb /\d+/, "jeu du 7, 14 et 21";    # -> 7 14 21
# syntaxe de méthode :
say "3 fois 6 font 18".comb(/\d+/).join(" ");      # -> 3 6 18

Sans être spécifiques aux regex, d'autres fonctions ou méthodes établissant une condition booléenne peuvent utiliser un motif de regex (ou autre chose, par exemple une comparaison numérique) pour définir cette condition. Ainsi, la fonction first, qui renvoie le premier élément d'une liste satisfaisant une condition, et la fonction grep, qui renvoie tous les éléments d'une liste satisfaisant une condition, peuvent s'écrire avec une regex :

say first /ma/, <jan fév mar avr mai>;             # -> mar
say grep  /ma/, <jan fév mar avr mai>;             # -> (mar mai)
say <jan fév mar avr mai>.grep(/v/);               # -> (fév avr)

La construction given ... when (le « switch » de Perl 6) utilise également bien souvent des regex :

my $var = '42';
given $var { 
    when /^4/   { say "Commence par '4'"; proceed}; 
    when /2$/   { say "Finit par '2'"; proceed}; 
    when /^42$/ { say "Réponse à la Grande Question sur l'Univers" }
}

Perl 6 offre les constructions syntaxiques suivantes pour écrire des regex :

m/abc/;         # une regex immédiatement appliquée à $_
rx/abc/;        # un objet de type Regex
/abc/;          # un objet de type Regex

Les deux premières syntaxes peuvent utiliser d'autres délimiteurs que la barre oblique :

m{abc};         # ou m[abc];
rx{abc};        # ou rx!abc!;

À noter cependant que le caractère deux-points («:») ne peut pas servir de délimiteur pour des regex. Les parenthèses ordinaires («(» et «)») ne peuvent servir de délimiteur que si la parenthèse ouvrante est séparée par au moins un espace de l'opérateur rx qui le précède (c'est une règle générale de Perl 6 : une parenthèse ouvrante accolée à l'identifiant qui précède est analysée comme le début d'un appel de fonction) :

my $regex = rx(toto);  # ERRONÉ, interprété comme appel de fonction
my $regex = rx (toto); # OK

D'une façon générale, les espaces blancs à l'intérieur des motifs sont ignorés par défaut, sauf en cas de l'utilisation (explicite ou implicite) de l'adverbe :s ou :sigspace, voir § 2.9.1.2. plus bas) .

say "Reconnu" if "abc" ~~ /a b  c /;    # -> "Reconnu"

Comme dans le reste de Perl 6, les commentaires commencent habituellement avec le caractère croisillon «#» (souvent appelé caractère dièse par erreur, le dièse est différent : «♯»), sauf si ce croisillon est protégé par le caractère d'échappement « \ », et vont jusqu'à la fin de la ligne (et sauf si le croisillon est utilisé comme délimiteur, auquel cas il est nettement préférable de ne pas essayer de s'en servir comme caractère de début de commentaire). Les commentaires multilignes sont également possibles.

# Commentaires unilignes :
my $regex = rx {
                 abc         # chaîne littérale 'abc'
                 \d          # suivie d'un chiffre
                 \w          # puis d'un caractère alphanumérique.
};

# Commentaire multiligne :
my $regex = rx { 
                 abc \d \w   #`[ chaîne littérale 'abc' suivie d'un
                                 chiffre puis d'un caractère
                                 alphanumérique quelconque.
                               ]
};
say "Reconnu" if "XYabc6QUVW" ~~ /<$regex>/; # reconnaît 'abc6Q'

Le cas le plus simple de motif de reconnaissance d'une regex est une chaîne constante. Dans ce cas, reconnaître un motif consiste à rechercher le motif comme une sous-chaîne de la chaîne :

my $chaîne = "Esperluette est le nom parfois donné au signe &";
if $chaîne ~~ m/ perl / {
    say '$chaîne contient "perl"'; # -> $chaîne contient "perl"
}

Tous les caractères alphanumériques (Unicode) et le caractère souligné ou underscore («_») sont des reconnaissances littérales. Tous les autres caractères (signes de ponctuation, symboles, etc.) doivent être protégés par le caractère d'échappement antislash («\») ou être cités entre apostrophes (ou guillemets simples) :

/ 'deux mots' /    # reconnaît 'deux mots', espace blanc compris
/ "a:b"       /    # reconnaît 'a:b', caractère deux-points compris
/ '#' /            # reconnaît le caractère croisillon (ou hash)
/moi\@gmail\.com/  # échappements pour protéger l'@ et le .
/'moi@gmail.com'/  # équivalent à : /moi\@gmail\.com/

Lorsqu'ils sont protégés par un caractère d'échappement, les caractères alphanumériques prennent souvent une signification particulière : par exemple, le métacaractère \d représente une classe de caractères pouvant signifier un chiffre quelconque (Unicode) ; de nombreux exemples seront donnés plus loin (notamment au § 2.3.1.).

Les chaînes de caractères sont explorées de gauche à droite, il suffit donc, par exemple, qu'une sous-chaîne soit égale au motif :

if 'abcdefg' ~~ / de / {
    say ~$/;           # de -> motif reconnu
    say $/.prematch;   # abc -> ce qui précède le motif reconnu
    say $/.postmatch;  # fg -> ce qui suit le motif reconnu
    say $/.from;       # 3 -> position du début de la reconnaissance
    say $/.to;         # 5 -> position de ce qui suit la reconnaissance
};

Les résultats de la reconnaissance sont stockés dans la variable $/ (représentant le match object, que l'on traduira dans ce document par « objet reconnu », même si le terme anglais veut parfois aussi dire « objet de type Match »), et sont également renvoyés par la reconnaissance. Le résultat est de type Match si la reconnaissance a réussi, et Nil sinon.

Une classe de caractères est un élément de syntaxe des regex qui permet de reconnaître non plus un seul caractère déterminé, mais un caractère appartenant à tout un ensemble de caractères ayant éventuellement des traits communs (reconnaître par exemple l'un quelconque des chiffres de 0 à 9, ou l'un quelconque des caractères alphabétiques minuscules).

Le point («.») reconnaît tout caractère simple (sauf s'il est précédé d'un caractère d'échappement, auquel cas il reconnaît un point littéral) :

'perl'   ~~ /per./;       # Reconnaît toute la chaîne
'perl'   ~~ / per . /;    # Idem (espaces blancs ignorés);
'perl'   ~~ / pe.l /;     # Idem: le . reconnaît le r
'Épelle' ~~ / pe.l/;      # Idem: le . reconnaît le premier l

'perl' ~~ /. per /        # Pas de reconnaissance: 
                          # le . ne reconnaît rien avant la chaîne per

Contrairement à Perl 5 et à de nombreux langages dont le système d'expressions régulières dérive de Perl 5, le point reconnaît aussi toujours le caractère retour à la ligne.

2-3-1. Caractère d'échappement et classes de caractères prédéfinies▲

2-3-2. Propriétés Unicode▲

'perl6' ~~ m{\w+(<:Ll+:N>)}       # 0 => ｢6｣

2-3-3. Classes de caractères énumérées et intervalles▲

"abacabadabacaba" ~~ / <[ a .. d 1 2 3 ]> / # Vrai

say 'pas de guillemets' ~~ /  <-[ " ]> + /;  
      # reconnaît les caractères autres que "

say 'entre guillemets' ~~ / '"' <-[ " ]> * '"'/;
      # un guillemet, suivi de non-guillemets, suivi d'un guillemet

Un quantificateur permet de reconnaître non pas exactement une fois, mais plutôt un nombre fixe ou variable de fois, l'atome qui le précède. Par exemple, le quantificateur «+» cherche à reconnaître une ou plusieurs fois ce qui précède.

Les quantificateurs ont une précédence plus forte que la concaténation, si bien que / ab+ / reconnaît la lettre a suivie d'une ou plusieurs fois la lettre b. La situation est inversée avec des apostrophes : / 'ab'+ / reconnaît les chaînes 'ab', 'abab' 'ababab', etc.

2-4-1. Avidité et frugalité des quantificateurs▲

say ~$/ if 'aabaababa' ~~ / .+ b /;      # -> aabaabab

say ~$/ if 'aabaababa' ~~ / .+? b /;     # -> aab

Pour reconnaître une possibilité parmi plusieurs, il faut les séparer par «||» ; la première reconnaissance trouvée (de gauche à droite) l'emporte. Par exemple les fichiers d'initialisation (du style config.ini) ont souvent la forme suivante :

[section]
clef = valeur

Quand on lit une ligne d'un fichier de ce genre, ce peut être soit une section, soit une paire clef-valeur. En première approche, la regex pour lire ce type de fichier pourrait être :

/ '[' \w+ ']' || \S+ \s* '=' \s* \S* /

C'est-à-dire :

• soit un mot entre crochets ;
• soit une chaîne composée de caractères autres que des espaces blancs, suivie de 0 ou plusieurs espaces, suivis du signe égal « = », suivi à nouveau d'espaces optionnels, suivis d'une autre chaîne composée de caractères autres que des espaces blancs.

Il existe une autre forme d'alternative, utilisant le séparateur «|» (au lieu de «||»). L'idée est la même, mais c'est la reconnaissance la plus longue (en non plus la première) qui est retenue (à condition de commencer au même emplacement), ce qui implique qu'elles doivent toutes être testées (éventuellement en parallèle) et comparées.

L'exemple ci-dessous illustre la différence entre les deux opérateurs :

my $chaîne = "abcdef";
say ~$/ if $chaîne ~~ /ab || abcde/;       # -> ab
say ~$/ if $chaîne ~~ /ab |  abcde/;       # -> abcde
say ~$/ if $chaîne ~~ /ab |  bcde/;        # -> ab
# dans ce dernier cas, la reconnaissance la plus à gauche l'emporte

La règle de la reconnaissance la plus longue est particulièrement utile pour procéder à l'analyse lexicale d'une chaîne de caractères appartenant par exemple à du code Perl. Ainsi, c'est elle qui permet à la grammaire Perl de reconnaître des identifiants (de variables, de fonctions, etc.) contenant des tirets (à condition qu'ils soient suivis d'un caractère alphabétique) : Perl est capable de reconnaître un tel identifiant (et de le distinguer par exemple d'un opérateur arithmétique moins placé entre deux symboles distincts) grâce à cette règle de la reconnaissance la plus longue.

2-5-1. Conjonction (reconnaître ceci et cela)▲

my $regex = rx/a..d & .bcd/;
say "Reconnu" if "XZabcdZ" ~~ /$regex/;    # -> Reconnu
say ~$/;                                   # -> abcd

Le moteur de regex essaie de trouver une correspondance dans une chaîne en cherchant de gauche à droite.

say so 'Saperlipopette' ~~ / perl /;   # True 
#         ^^^^
# (so renvoie une évaluation booléenne, donc, en fait True ou False)

Mais ce n'est pas toujours ce que l'on désire. Par exemple, on peut vouloir reconnaître toute la chaîne, ou toute une ligne, ou un ou plusieurs mots entiers, ou attacher de l'importance à l'endroit de la chaîne où la reconnaissance se produit (par exemple uniquement en début de chaîne). Les ancres (et les assertions étudiées plus loin au § 2.10.) permettent de spécifier où la reconnaissance aura lieu.

Il faut que les ancres d'une regex soient reconnues pour que l'ensemble de la regex le soit, mais les ancres ne consomment pas de caractère dans la chaîne.

2-7-1. Regroupements▲

say 1 + 4 * 2;      # 9, analysé comme : 1 + (4 * 2)
say (1 + 4) * 2;    # 10

/ a || b c /        # reconnaît 'a' ou 'bc'
/ ( a || b ) c /    # reconnaît 'ac' ou 'bc'

/ a b+ /            # Reconnaît un 'a' suivi d'un ou plusieurs 'b'
/ (a b)+ /          # Reconnaît une ou plusieurs séquences 'ab'
/ (a || b)+ /       # Reconnaît une séquence quelconque de 'a' et
                    # de 'b' longue d'au moins un caractère

2-7-2. Captures▲

my $str =  'nombre 42';
if $str ~~ /'nombre ' (\d+) / {
    say "Le nombre est $0";         # Le nombre est 42
    # ou
    say "Le nombre est $/[0]";      # Le nombre est 42
}

if 'abc' ~~ /(a) b (c)/ {
    say "0: $0; 1: $1";             # 0: a; 1: c
}

if 'abcdef' ~~ /(a) b (c) (d) e (f)/ {
    say $/.list.join: ', '  # a, c, d, f
}

2-7-3. Regroupements sans capture▲

if 'abc' ~~ / [a||b] (c) / {
    say ~$0;                # c
}

2-7-4. Numérotation des captures▲

/ (x) (y)  || (a) (.) (.) /
# $0  $1      $0  $1  $2

if 'abc' ~~ /(x)(y) || (a) (.) (.)/ {
#                       $0  $1  $2
    say ~$1;            # b
}

$chaîne = 'abcd';
if $chaîne / a [ b (.) || (x) (y) ] (.) / {
    #              $0     $0  $1    $2
    say ~$2;            # d
}

if 'abc' ~~ / ( a (.) (.) ) / {
    say "Extérieur: $0";              # Extérieur: abc
    say "Intérieur: $0[0] et $0[1]";  # Intérieur: b et c
}

2-7-5. Captures nommées▲

if 'abc' ~~ / $<mon_nom> = [ \w+ ] / {
    say ~$<mon_nom>      # abc
}

if 'décompte=23' ~~ / $<variable>=\w+ '=' $<valeur>=\w+ / {
    my %h = $/.hash;
    say %h.keys.sort.join: ', ';        # valeur, variable
    say %h.values.sort.join: ', ';      # 23, décompte
    for %h.kv -> $k, $v {
        say "Trouvé valeur '$v' avec la clef '$k'";
        # Affiche ces deux lignes :
        #   Trouvé valeur 'décompte' avec la clef 'variable'
        #   Trouvé valeur '23' avec la clef 'valeur'
    }
}

Il est possible de mettre des morceaux de regex dans des règles nommées, de même que l'on peut mettre des fragments de code dans une fonction (ou subroutine) ou une méthode.

my regex ligne { \N*\n }
if "abc\ndef" ~~ /<ligne> def/ {
    say "Première ligne: ", $<ligne>.chomp;    # Première ligne: abc
}

Une regex nommée peut se déclarer avec la syntaxe my regex nom_regex {corps de la regex }, et appelée ensuite avec <nom_regex>. En outre, invoquer une regex nommée crée ipso facto une capture nommée portant le même nom ($<ligne> dans l'exemple ci-dessus).

Il est toutefois possible, si on le désire, de donner un autre nom à la capture, avec la syntaxe d'appel suivante <nom_capture=nom_regex> ; on peut ensuite accéder à la capture avec la notation $<nom_capture>. Nous donnons un exemple de l'emploi de cette fonctionnalité dans la grammaire MultDiv du § 3.9.1. (Composition de rôles).

Si l'on n'a pas besoin de capture, préfixer le nom de la regex d'un point, <.nom_regex>, supprimera la capture.

Voici un extrait de code un peu plus complet (mais cependant encore assez limité) pour analyser le fichier de type config.ini du § 2.5. :

my regex entête { \s* '[' (\w+) ']' \h* \n+ }
my regex identifiant  { \w+ }
my regex kvpair { \s* <clef=identifiant> '=' <val=identifiant> \n+ }
my regex section {
    <entête>
    <kvpair>*
}

# Exemple de fichier ini dans un document "ici même" :
my $contenu = q:to/FIN_INI/;
    [passwords]
        jean=mdp1
        anne=plusfiable123
    [quotas]
        jean=123
        anne=42
FIN_INI

my %config;
if $contenu ~~ /<section>*/ {
    for $<section>.list -> $section {
        my %section;
        for $section<kvpair>.list -> $p {
            say $p<val>;
            %section{ $p<clef> } = ~$p<val>;
        }
        %config{ $section<entête>[0] } = %section;
    }
}
say %config.perl;
# ("passwords" => {"jean" => "mdp1", "anne" => "plusfiable123"},
#    "quotas" => {"jean" => "123", "anne" => "42"}).hash

Les regex nommées peuvent être regroupées en grammaires (voir § 3.) et il est souvent souhaitable de le faire (l'objectif des regex nommées est précisément de construire des grammaires).

Il existe des sous-règles prédéfinies, correspondant plus ou moins aux classes de caractères vues antérieurement, par exemple :

• ident : un identifiant ;
• upper : un seul caractère capital ;
• lower : un seul caractère minuscule ;
• alpha : un seul caractère alphabétique ou un caractère souligné «_» (pour un caractère alphabétique Unicode sans le caractère souligné, utiliser <:alpha> ;
• digit : un seul chiffre ;
• xdigit : un seul chiffre hexadécimal ;
• print : un seul caractère imprimable ;
• punct : un seul caractère ponctuation ;
• alnum : un seul caractère alphanumérique (équivalent à <+alpha +digit>) ;
• wb : limite de mot, assertion de longueur nulle ;
• space : un seul espace blanc (même chose que \s) ;
• before motif : assertion avant de longueur nulle, c'est-à-dire vérifie si l'on est à une position où le motif est reconnu et renvoie un objet reconnu de taille nulle en cas de succès (il existe de même une sous-règle after motif vers l'arrière). Voir aussi § 2.10.).

Une liste plus complète se trouve dans la Synopse S05.

Comme on le verra au chapitre suivant, une regex nommée ou sous-règle peut également être définie avec les mots-clefs token ou rule (en lieu et place de regex), ce qui modifie la façon dont le moteur de regex analysera la chaîne en utilisant implicitement les adverbes :ratchet et/ou (selon le cas) :sigspace (voir les sections 2.9.1.1. et 2.9.1.2. ci-dessous). La syntaxe de la déclaration est alors la suivante :

my token nom-de-règle { ... }
# ou :
my rule  nom-de-règle { ... }

Les adverbes (qui correspondent à ce que l'on appelait modificateurs en Perl 5 et dans les packages de regex issus de Perl 5 employés dans d'autres langages comme PCRE) modifient la façon dont fonctionnent les regex et permettent des raccourcis très pratiques pour certaines tâches répétitives.

Il y a deux sortes d'adverbes : les adverbes de regex s'appliquent là où la regex est définie et les adverbes de reconnaissance là où le motif reconnaît une chaîne. La distinction est parfois un peu floue, car la reconnaissance et la définition sont souvent textuellement rapprochées, mais utiliser la syntaxe de méthode de la reconnaissance aide à clarifier la différence.

'abc' ~~ /../ équivaut à peu près à 'abc'.match(/../) et peut même s'écrire plus clairement en deux lignes distinctes :

my $regex = /../;           # définition, deux caractères quelconques
if 'abc'.match($regex) {    # reconnaissance
    say "'abc' a au moins deux caractères";
}

Les adverbes de regex comme :i(ignorer la casse, c'est-à-dire la distinction entre lettres capitales et minuscules) vont dans la définition alors que des adverbes de reconnaissance comme :overlap (chevauchement) sont ajoutés à l'appel de la reconnaissance :

my $regex = /:i . a/;
for 'baA'.match($regex, :overlap) -> $m {
    say ~$m;
}
# Affiche :
#     ba
#     aA

2-9-1. Adverbes de regex▲

my $rx1 = rx:i/a/;      # avant
my $rx2 = rx/:i a/;     # à l'intérieur

my $rx3 = rx/a :i b/;   # insensible à la casse seulement pour b
my $rx4 = rx/:i a b/;   # complètement insensible à la casse

/ (:i a b) c /          # reconnaît 'ABc' mais pas 'ABC'
/ [:i a b] c /          # reconnaît 'ABc' mais pas 'ABC'

say so 'abc' ~~ / \w+ . /;      # Vrai
say so 'abc' ~~ / :r \w+ . /;   # Faux

my token truc { .... }
# raccourci pour :
my regex truc { :r ... }

say so "J'ai utilisé Photoshop®"  ~~ m:i/   photo shop /; # Vrai
say so "J'ai utilisé photo shop"  ~~ m:i:s/ photo shop /; # Vrai
say so "J'ai utilisé Photoshop®"  ~~ m:i:s/ photo shop /; # Faux

rx :s {
    ^^
    {
        say "Pas de sigspace après ceci";
    }
    <.assertion_puis_ws>
    caractères_puis_ws+
    caractères_séparés_par_ws *
    [
    | des "trucs" .. .
    | $$
    ]
    :my $toto = "pas de ws après ceci";
    $toto
}

rx {
    ^^ <.ws>
    {
        say "Pas d'espace après ceci";
    }
    <.assertion_puis_ws> <.ws>
    caractères_puis_ws++ <.ws>
    [ caractères_séparés_par_ws <.ws>]* <.ws>
    [
    | des <.ws> "trucs" <.ws> .. <.ws> . <.ws>
    | $$ <.ws>
    ] <.ws>
    :my $toto = "pas de ws après ceci";
    $toto <.ws>
}

grammar Demo {
    token ws {
        <!ww>   # reconnaissance si pas à l'intérieur d'un mot
        \h*     # reconnaît seulement les espaces horizontaux
    }
    rule TOP {  # appelée par Demo.parse;
        a b '.'
    }
}

say so Demo.parse("ab.");       # Faux (espace requis entre a et b)
say so Demo.parse("a b.");      # Vrai
say so Demo.parse("a\tb .");    # Vrai
say so Demo.parse("a\tb\n.");   # Faux (\n est un espace vertical)

next if $ligne =~ m/[aeiou]/   ;    # Classe de caractères Perl 5
next if $ligne ~~ m:P5/[aeiou]/   ; # Perl 6, avec l'adverbe P5
next if $ligne ~~ m:Perl5/[aeiou]/; # Perl 6, avec l'adverbe Perl5
next if $ligne ~~ m/  <[aeiou]> / ; # Perl 6, nouvelle syntaxe des
                                    # classes de caractères

2-9-2. Les adverbes de reconnaissance▲

given 'a1xa2' {
    say ~m/a./;         # a1
    say ~m:c(2)/a./;    # a2 (la recherche commence à la position du x)
}

given 'abracadabra' {
    for m:exhaustive/ a .* a / -> $match {
        say ' ' x $match.from, ~$match;
    }
}

abracadabra
abracada
abraca
abra
   acadabra
   acada
   aca
     adabra
     ada
       abra

given 'Trois mots ici' {
    my @matches = m:global/\w+/;
    say @matches.elems;         # 3
    say ~@matches[2];           # ici
}

given 'abcdef' {
    my $trouvé = m:pos(2)/.*/;
    say $trouvé.from;        # 2
    say ~$trouvé;            # cdef
}

given 'abracadabra' {
    for m:overlap/ a .* a / -> $match {
        say ' ' x $match.from, ~$match;
    }
}

abracadabra
   acadabra
     adabra
       abra

Les assertions permettent de rechercher des correspondances vers l'avant ou vers l'arrière, mais sans consommer la chaîne cible (en restant à la même position), comme le font les ancres.

2-10-1. Assertions avant▲

say "tototiti" ~~ rx{ toto <?before titi>};   # -> toto

2-10-2. Assertions arrière▲

say "tititoto" ~~ rx{ <?after titi> toto };   # -> toto

Une grosse partie de ce qu'il y a besoin de savoir et de comprendre pour écrire une grammaire a déjà été vue ci-dessus, en particulier au chapitre 2.8. Sous-règles ou règles nommées, ainsi qu'aux sous-chapitres 2.9.1.1. et 2.9.1.2. ci-dessus. Ces sous-règles ou règles nommées constituent les briques élémentaires d'une grammaire. En fait, l'un des principaux buts d'une grammaire est de regrouper des sous-règles ou regex nommées (de types regex, token et rule) dans un espace de noms bien délimité afin d'éviter les collisions de noms d'identifiants avec d'autres regex ailleurs dans le code.

Rappelons que les regex, token et rule sont des entités très semblables servant à déclarer une regex nommée sous une forme ressemblant à la définition d'une fonction ou d'une méthode. Dans ce chapitre, nous les appellerons désormais collectivement règles, indépendamment du mot-clef utilisé pour les déclarer. On les déclare de la façon suivante :

regex ma_regex  { ... }  # regex ordinaire
token mon_token { ... }  # regex avec adverbe :ratchet implicite
rule ma_règle   { ... }  # regex avec :ratchet et :sigspace implicites

Pour mémoire :

• Le mot-clef regex signale une regex ordinaire ;
• Le mot-clef token implique l'adverbe :ratchet (« cliquet ») implicite, c'est-à-dire que ce genre de règle ne fait pas de retour arrière (pas de backtracking) ;
• Le mot-clef rule indique implicitement les adverbes :ratchet (pas de retour arrière) et :sigspace (les espaces du motif ne sont pas ignorés).

Voici un exemple dans lequel on définit une première règle chiffres , et l'utilise pour en définir une seconde, décimal :

my regex chiffres { \d+ }
my regex décimal { <chiffres> \. <chiffres> }
say so " Cet objet coûte 13.45 euros" ~~ /<décimal>/; # -> True
# (so renvoie une évaluation booléenne, donc, en fait True ou False)
say ~$/;                                              # -> 13.45

On voit ci-dessus qu'une règle peut appeler une autre règle, de même qu'une fonction peut appeler une autre fonction. Une règle peut aussi s'appeler elle-même récursivement. Ce mécanisme capital est le cœur de la puissance des regex de Perl 6 et de leur capacité à créer des grammaires.

Une règle de type token ne fait pas de retour arrière :

my token lettres { abc .+ g };
say "abcdefg" ~~ /<lettres>/ ?? "Réussit" !! "Échoue"; # ->  Échoue

Cette règle échoue ici parce que le sous-motif .+ , avec son quantificateur gourmand «+», consomme toute la fin de la chaîne, y compris la dernière lettre « g », si bien que la règle ne peut plus reconnaître le « g » final déjà consommé : comme elle n'est pas autorisée à revenir en arrière pour abandonner le « g » et le laisser à la disposition du dernier atome du motif afin de parvenir à réussir, elle échoue.

Avec un quantificateur non gourmand (ou frugal), la règle lettres modifiée réussit :

my token lettres { abc .+? g };
say "abcdefg" ~~ /<lettres>/ ?? "Réussit" !! "Échoue"; # ->  Réussit

Avec une définition identique, une règle de type rule échoue :

my rule  lettres { abc .+? g };
say "abcdefg" ~~ /<lettres>/ ?? "Réussit" !! "Échoue"; # ->  Échoue

parce que les espaces présents dans le motif ne sont plus ignorés (et qu'on ne les retrouve pas dans la chaîne).

Les noms des trois types de règles nommées, regex, token et rule, reflètent l'idée que, d'une façon très générale et assez floue, dans une grammaire, une regex fait à peu près ce que l'on attend usuellement d'une expression régulière (analyse de bas niveau, caractère par caractère), alors qu'une token va souvent servir plutôt à l'analyse lexicale (division du texte en entrée en « mots » ou lexèmes individuels) et qu'une rule sera plus souvent destinée à l'analyse syntaxique (analyse du rapport entre les lexèmes, éventuellement en fonction du contexte). Cette répartition théorique des tâches est sujette à de très nombreuses exceptions et ne doit surtout pas être suivie de façon dogmatique, mais il n'est pas inutile de conserver cette idée à l'esprit lors de la décision de choix entre les différents types de règles.

Une grammaire crée un espace de noms propre et s'introduit avec le mot-clef grammar.

3-2-1. Syntaxe de définition d'une grammaire▲

class Identité {
    method nom     { "Nom = $!nom"     }
    method âge     { "Âge = $!âge"     }
    method adresse { "Adr = $!adresse" }

    method desc {
        print &.nom(),     "\n",
              &.âge(),     "\n",
              &.adresse(), "\n";
    }

    # etc.
}

grammar Identité {
    rule nom     { Nom '=' (\N+) } # chaîne de caractères quelconques
                                   # autres que des retours à la ligne
    rule adresse { Adr '=' (\N+) } # idem
    rule âge     { Age '=' (\d+) } # des chiffres

    rule desc {
        <nom>     \n
        <âge>     \n
        <adresse> \n
    }

    # etc.
}

3-2-2. Héritage de grammaires▲

grammar Message {
    rule texte     { <salutation> $<corps>=<ligne>+? <fin> }
    rule salutation    { [Salut|Bonjour] $<dest>=\S+? ',' }
    rule fin    { [à|'@'] plus ',' $<auteur>=.+ }
    token ligne    { \N* \n}
}

grammar MessageFormel is Message {
    rule salutation { [Cher|Chère] $<dest>=\S+? ',' }
    rule fin { Bien cordialement ',' $<auteur>=.+ }
}

Il est possible d'analyser une chaîne de caractères avec une grammaire en appelant la méthode .parse sur cette grammaire et en passant optionnellement en paramètre un objet d'actions (voir § 3.4. ci-dessous). De même, la méthode .parsefile permet d'analyser un fichier.

MaGrammaire.parse($chaîne, :actions($objet-action))
MaGrammar.parsefile($nom-fic, :actions($objet-action))

Les méthodes .parse et .parsefile sont ancrées au début et à la fin du texte, et échouent si la fin du texte n'est pas atteinte.

En principe, il ne faut utiliser une grammaire que pour effectuer l'analyse lexicale et syntaxique proprement dite du texte. Pour extraire des données complexes, il est recommandé d'utiliser un objet d'actions en conjonction avec la grammaire.

3-4-1. Exécuter du code lors d'une reconnaissance ▲

use v6;

grammar GrammaireTest {
    token TOP { ^ \d+ $ }
}

class ActionsTest {
    method TOP($/) {
        $/.make(2 + ~$/);
    }
}

my $actions = ActionsTest.new;
my $reconnu = GrammaireTest.parse('40', :$actions);
say $reconnu;          # -> ｢40｣
say $reconnu.made;     # -> 42

use v6;

grammar PairesClésValeurs {
    token TOP {
        [<paire> \n+]*
    }
    token ws { \h* }

    rule paire {
        <clé=.identifiant> '=' <valeur=.identifiant>
    }
    token identifiant {
        \w+
    }
}

class PairesClésValeursActions {
    method identifiant($/) { $/.make: ~$/                           }
    method paire      ($/) { $/.make: $<clé>.made => $<valeur>.made }
    method TOP        ($/) { $/.make: $<paire>».made                }
}

my  $res = PairesClésValeurs.parse(q:to/EOI/, :actions(PairesClésValeursActions)).made;
    phase=b
    points=42
    Perl=6
    EOI

for @$res -> $p {
    say "Clef : $p.clé()\tValeur : $p.valeur()";
}

Clef : phase      Valeur : b
Clef : points     Valeur : 42
Clef : Perl       Valeur : 6

3-4-2. Autres façons d'exécuter du code dans une grammaire▲

grammar Toto {
    regex titi { <.configurer> blah blah }
    method configurer {
        # faire quelque chose ici
    }
}

grammar toto {
    regex titi { blah blah { say "Je suis arrivé ici"} blah blah}
}

my regex lettres { a b {say "reconnu ab"} c d}
say so  "abc" ~~ /<lettres>/; # -> reconnu ab / False
# la regex ci-dessus a reconnu ab et l'affiche et n'a échoué qu'ensuite
say so  "abcde" ~~ /<lettres>/; # -> reconnu ab / True - ici, succès

say so "aaa" ~~ / a { say "Bonjour" } b /;

Bonjour
Bonjour
Bonjour
False

L'objectif de cet exemple est de valider un nom de module Perl.

Le nom d'un module Perl peut se décomposer en identifiants séparés par des paires de caractères deux-points : « :: », par exemple List::Util ou List::MoreUtils (les exemples de noms de modules fournis ici sont des modules Perl 5). Un identifiant doit commencer par un caractère alphabétique (a-z) ou un caractère souligné, suivi de zéro, un ou plusieurs caractères alphanumériques.

Rien de bien complexe jusqu'ici, mais ceci se complique quelque peu du fait que certains modules ont un seul identifiant (Memoize), et donc pas de caractères deux-points, et que d'autres peuvent avoir des noms « à rallonge » : Regexp::Common::Email::Address.

N'est-ce pas un bon candidat pour une grammaire ?

3-5-1. La grammaire de validation▲

grammar Valide-Nom-Module {
    token TOP { ^ <identifiant> [ <séparateur> <identifiant> ]* $}
    token identifiant { 
        <[A..Za..z_]>      # 'mot' commençant par un caractère 
                           # alphabétique ou un caractère souligné 
        <[A..Za..z0..9_]>*  # 0 ou plusieurs caractères alphanumériques
    }
    rule séparateur { '::' }    # paire de caractères deux-points
}

for  <Super:Nouveau::Module Super.Nouveau.Module 
      Super::6ouveau::Module Super::Nouveau::Module> -> $nom {
    my $reconnu =  Valide-Nom-Module.parse($nom);
    say "nom\t", $reconnu ?? $reconnu !! "Nom de module invalide";
}

Super:Nouveau::Module   Nom de module invalide
Super.Nouveau.Module    Nom de module invalide
Super::6ouveau::Module  Nom de module invalide
Super::Nouveau::Module  ｢Super::Nouveau::Module｣
 identifiant => ｢Super｣
 séparateur => ｢::｣
 identifiant => ｢Nouveau｣
 séparateur => ｢::｣
 identifiant => ｢Module｣

rule séparateur { '::' || \- }    # deux car. deux-points ou tiret

Super-Nouveau-Module  ｢Super-Nouveau-Module｣
 identifiant => ｢Super｣
 séparateur => ｢-｣
 identifiant => ｢Nouveau｣
 séparateur => ｢-｣
 identifiant => ｢Module｣

3-5-2. Ajout d'un objet d'actions▲

class Valide-Nom-Module-Actions {
    method TOP($/) {
        if $<identifiant>.elems > 5 {
            warn "Nom de module très long! Peut-être le réduire ?\n"
        }
    }
}

my $reconnu =  Valide-Nom-Module.parse($nom, :actions(Valide-Nom-Module-Actions));

my $nom = "Mon::Module::Super::Cali::Fragi::Listi::Cexpi::Delilicieux";
my $reconnu =  Valide-Nom-Module.parse($nom, :actions(Valide-Nom-Module-Actions));
say $reconnu if $reconnu;

> perl6 grammaire_nom_module.pl
Nom de module très long! Peut-être le réduire ?
  in method TOP at perl6_grammaire_module.pl:15
｢Mon::Module::Super::Cali::Fragi::Listi::Cexpi::Delilicieux｣
 identifiant => ｢Mon｣
 séparateur => ｢::｣
 identifiant => ｢Module｣
 séparateur => ｢::｣
 identifiant => ｢Super｣
(...)
 identifiant => ｢Delilicieux｣

my $nom = "Mon::Module::Super::Cali::Fragi::Listi::Cexpi::Delilicieux";
my $actions = Valide-Nom-Module-Actions.new();
my $reconnu =  Valide-Nom-Module.parse($nom, :actions($actions));

perl6 grammaire_nom_module.pl
Nom de module très long! Peut-être le réduire ?
  in method TOP at perl6_grammaire_module.pl:15

Le JSON (JavaScript Object Notation) est un format de données textuelles dérivé de la notation des objets du langage JavaScript. Il est devenu (avec d'autres comme XML et YAML) un standard communément utilisé pour sérialiser des structures de données, ce qui permet par exemple de les échanger entre des plates-formes ou des langages différents, ou de les stocker de façon persistante (dans un fichier, par exemple).

3-6-1. Structure d'un document JSON▲

3-6-2. Exemple de document JSON▲

{
  "prénom": "Martine",
  "nom": "Unetelle",
  "enVie": true,
  "âge": 28,
  "sexe": "F",
  "adresse": {
    "NumRue": "21 rue Pasteur",
    "Ville": "Lyon",
    "CodePostal": "F-69000"
  },
  "NumérosTéléphone": [
    {
      "type": "domicile",
      "num": "04 05 06 07 08"
    },
    {
      "type": "professionnel",
      "num": "04 08 07 06 05"
    },
    {
      "type": "mobile",
      "num": "06 12 34 56 78"
    }
  ],
  "enfants": [],
  "Conjoint": null,
  "Profession": "sage-femme",
  "Hobbies": ["GRS", "surf", "peinture"]
}

3-6-3. Écrire pas à pas les éléments de la grammaire JSON▲

token nombre {
    [\+|\-]?             # signe optionnel
    [ <[0..9]>* ]        # chiffres optionnels (partie entière)
    [ \. <[0..9]>+ ]?    # séparateur décimal et partie fractionnaire
    [ <[eE]> [\+|\-]? <[0..9]>+ ]?  # exposant optionnel
}

token chaîne {
    \" <[  \w \s - ]>+ \" # caractères alphanumériques, espaces et
                          # tirets, le tout entre des guillemets
}

token chaîne {
    \" <-[\n " \t]>* \"  # tous caractères sauf guillemets, retours à
                         # la ligne et tabulations, entre guillemets
}

rule objet       { '{'  <listepaires> '}' }
rule listepaires { <paire> * % \,         }
rule paire       { <chaîne> ':' <valeur>  }

rule listepaires { \s* | [<paire> [',' <paire>]*] }

rule tableau       { '[' <listeTableaux> ']'}
rule listeTableaux {  <valeur> * % [ \, ]  }

token valeur { | <objet> | <tableau> | <chaîne> | <nombre> 
               | true    | false     | null 
             }

proto token valeur {*};
token valeur:sym<nombre> {
    [  '-' | '+' ]?
    [ <[0..9]>* ]
    [ \. <[0..9]>+ ]?
    [ <[eE]> [\+|\-]? <[0..9]>+ ]?
}
token chaîne {
    \" <[  \w \s - ]>+ \"
}
token valeur:sym<true>    { <sym>     };
token valeur:sym<false>   { <sym>     };
token valeur:sym<null>    { <sym>     };
token valeur:sym<objet>   { <objet>   };
token valeur:sym<tableau> { <tableau> };
token valeur:sym<chaîne>  { <chaîne>  }

3-6-4. La grammaire JSON▲

grammar JSON-Grammaire {
    token TOP          { ^ \s* [ <objet> | <tableau> ] \s* $ }
    rule objet         { '{'  <listepaires> '}'  }
    rule listepaires   { <paire> * % \,          }
    rule paire         { <chaîne> ':' <valeur>   }
    rule tableau       { '[' <listeTableaux> ']' }
    rule listeTableaux {  <valeur> * % [ \, ]    }
    token chaîne       { \" (<[ \w \s - ]>+) \"  }    
    token nombre {
        [\+ | \-]?
        [ <[0..9]>* ]
        [ \. <[0..9]>+ ]?
        [ <[eE]> [\+ | \-]? <[0..9]>+ ]?
    }
    token valeur {
        | <objet> | <tableau> | <chaîne> | <nombre>
        | true    | false     | null 
    }
}

my $reconnu = JSON-Grammaire.parse($chaîne_json);
say ~$reconnu if $reconnu;

$ perl6 json_grammaire.pl
{
  "prénom": "Martine",
  "nom": "Unetelle",
  "enVie": true,
  "âge": 28,

               # [ ... affichage abrégé pour des raisons de place ] 

  "Profession": "sage-femme",
  "Hobbies": ["GRS", "surf", "peinture"]
}

3-6-5. Ajouter des actions▲

class JSON-actions {
    method TOP($/) {
        make $/.values.[0].made;
    };
    method objet($/) {
        make $<listepaires>.made.hash.item;
    }
    method listepaires($/) {
        make $<paire>>>.made.flat;
    }
    method paire($/) {
        make $<chaîne>.made => $<valeur>.made;
    }
    method tableau($/) {
        make $<listeTableaux>.made.item;
    }
    method listeTableaux($/) {
        make [$<valeur>.map(*.made)];
    }
    method chaîne($/) { make ~$0 }
    method nombre($/) { make +$/.Str; }
    method valeur($/) { 
        given ~$/ {
            when "true"  {make Bool::True;}
            when "false" {make Bool::False;}
            when "null"  {make Any;} # équivalent d'undef en Perl5
            default      {make $<val>.made}
        }  
    }
}

    token valeur {
        | <val=objet> | <val=tableau> | <val=chaîne> | <val=nombre>
        | true    | false     | null 
    }

my $j-actions = JSON-actions.new();
my $reconnu = JSON-Grammaire.parse($chaîne_json, :actions($j-actions));
say $reconnu.made if $reconnu;

{
    Conjoint => (Any), 
    Hobbies => [GRS surf peinture], 
    NumérosTéléphone => [
        {num => 04 05 06 07 08, type => domicile} 
        {num => 04 08 07 06 05, type => professionnel} 
        {num => 06 12 34 56 78, type => mobile}
    ], 
    Profession => sage-femme, 
    adresse => {
        CodePostal => F-69000 
        Complément_Adr => (Any), 
        NumRue => 21 rue Pasteur, 
        Ville => Lyon
    }, 
    enVie => True, 
    enfants => [0], 
    nom => Unetelle, 
    prénom => Martine, 
    sexe => F, 
    âge => 28
}

say $reconnu.made<adresse><CodePostal Ville>;     # -> (F-69000 Lyon)

Un chapitre consacré aux grammaires de l'article De Perl 5 à Perl 6 : approfondissements décrit pas à pas l'écriture d'une grammaire pour analyser un texte respectant un sous-ensemble de la norme XML.

Ce sous-ensemble est défini par la suite de tests suivante :

my @tests = (
    [1, 'abc'                       ],      # 1
    [1, '<a></a>'                   ],      # 2
    [1, '..<ab>foo</ab>dd'          ],      # 3
    [1, '<a><b>c</b></a>'           ],      # 4
    [1, '<a href="foo"><b>c</b></a>'],      # 5
    [1, '<a empty="" ><b>c</b></a>' ],      # 6
    [1, '<a><b>c</b><c></c></a>'    ],      # 7
    [0, '<'                         ],      # 8
    [0, '<a>b</b>'                  ],      # 9
    [0, '<a>b</a'                   ],      # 10
    [0, '<a>b</a href="">'          ],      # 11
    [1, '<a/>'                      ],      # 12
    [1, '<a />'                     ],      # 13
);

dans laquelle les chaînes associées à un premier champ égal à 1 sont considérées comme des chaînes XML bien formées, et celles dont le premier champ est à 0 sont considérées comme mal formées.

Le lecteur intéressé est vivement encouragé à aller lire ce chapitre, dont seule la grammaire finale sera citée ici :

grammar XML {
    token TOP   { ^ <xml> $ };
    token xml   { <text> [ <tag> <text> ]* };
    token text {  <-[<>&]>* };
    rule tag   {
        '<'(\w+) <attributes>*
        [
            | '/>'                 # a single tag
            | '>'<xml>'</' $0 '>'  # an opening and a closing tag
        ]
    };
    token attributes { \w+ '="' <-["<>]>* '"' };
};

Voici pour commencer cette section un exemple un peu simpliste d'un programme utilisant une grammaire faisant office de calculatrice capable d'évaluer des expressions arithmétiques élémentaires :

use v6.c;

grammar GrammaireArithmétique {
    token TOP { \s* <nombre> \s* <operation> \s* <nombre> \s*}
    token operation { <[^*+/-]> }
    token nombre { \d+ | \d+\.\d+ | \.\d+ }
}
class ActionsArithmétiques {
    method TOP($/) {
        given $<operation> {
            when '*' { $/.make([*] $/<nombre>)}
            when '+' { $/.make([+] $<nombre>)}
            when '/' { $/.make($<nombre>[0] / $<nombre>[1]) }
            when '-' { $/.make([-] $<nombre>) }
            when '^' { $/.make($<nombre>[0] ** $<nombre>[1]) }
        }
    }
}
for '   6*7  ', '46.2 -4.2', '28+ 14.0 ',
    '70 * .6 ', '126   /3', '6.4807407 ^ 2' -> $op {
        my $reconnu = GrammaireArithmétique.parse($op, :actions(ActionsArithmétiques));
        say "$reconnu\t= ", $reconnu.made;
}

La grammaire GrammaireArithmétique est particulièrement simple : on cherche à reconnaître un nombre, suivi d'un opérateur arithmétique (les quatre opérations de bases plus l'exponentiation), suivi d'un autre nombre.

La classe d'actions ActionsArithmériques ne produit pas à proprement parler un AST, mais se contente d'évaluer le résultat de l'opération arithmétique effectuée entre deux termes numériques.

À l'exécution, cela affiche les résultats suivants :

$ perl6 grammaire_arithm.pl6
   6*7          = 42
46.2 -4.2       = 42
28+ 14.0        = 42
70 * .6         = 42
126   /3        = 42
6.4807407 ^ 2   = 42.00000002063649

On constate que cela fonctionne plutôt bien, mais nous désirerions être en mesure de traiter des expressions arithmétiques plus complexes contenant plusieurs opérations, en tenant compte des règles de priorité usuelles entre opérations, et des parenthèses habituellement utilisées pour modifier ces priorités.

En particulier, nous voudrions traiter correctement les expressions arithmétiques suivantes :

• 3 + 4 + 5;
• 3 + 4 * 5; # Le résultat attendu est 23
• (3 + 4) * 5; # Le résultat attendu est 35

Pour aboutir à ce genre de résultat, nous devons traiter différemment les opérateurs ayant des priorités différentes. Dans la grammaire ci-dessous, une expression (expr) est constituée de plusieurs termes séparés par les opérateurs + ou -. Un terme est constitué d'un atome ou de plusieurs atomes séparés par les opérateurs * ou /. Et un atome est soit un nombre simple, soit une expression arithmétique entre parenthèses.

Ceci garantit le respect des règles de précédence : les multiplications et les divisions seront évaluées avant les additions et les soustractions puisque, lors de l'analyse d'une expr, il faut évaluer les termes individuels avant de pouvoir compléter l'évaluation d'une expression. De même, comme une expression entre parenthèses est un atome, il est nécessaire d'évaluer la valeur de l'atome avant de pouvoir achever l'évaluation d'un terme contenant une expression entre parenthèses se trouvant dans ce terme.

La grammaire est un peu plus complexe que précédemment, mais reste, au moins en apparence, relativement simple :

my grammar Calculette {
    rule TOP            { <expr> }
    rule expr           { <terme> + % <plus-moins-op> }
    token plus-moins-op { [< + - >] }
    rule terme           { <atome> + % <mult-div-op> }
    token mult-div-op   { [< * / >] }
    rule atome {
        | <nombre> { make +$<nombre> }
        | <expr-parenth> { make $<expr-parenth>.made}
    }
    rule nombre            { <signe> ? [\d+ | \d+\.\d+ | \.\d+ ] }
    rule expr-parenth     { '(' <expr> ')' }
    token signe          { [< + - >] }
}

Il convient de remarquer que, dans le cas d'une expression entre parenthèses, la règle expr est susceptible d'être appelée récursivement. Cette possibilité d'appels récursifs est un élément essentiel de la puissance des grammaires, mais il convient de prendre certaines précautions pour éviter le risque d'entrer dans une récursion infinie ; nous examinons ces précautions plus en détail dans la section 4.5. (Éviter le piège de la récursion gauche).

On peut également noter que nous avons intégré deux actions dans la grammaire (dans la règle atome). Nous avons fait ce choix en particulier pour des raisons pratiques : comme la règle atome contient des sous-règles nommées très différentes, il est un plus aisé d'intégrer l'action directement dans le contexte de la sous-règle. Si ces actions avaient été placées dans une classe d'actions, il aurait fallu déterminer quelle sous-règle avait été reconnue. Ce n'est pas bien difficile, mais cela aurait rendu le code un peu plus complexe. La seconde raison est d'ordre pédagogique : bien qu'il soit souvent préférable de créer une classe d'actions séparée (et nous allons le faire très bientôt dans cet exemple), il est utile de savoir que des actions peuvent occasionnellement être intégrées directement dans une grammaire. Pour une grammaire très simple, ce serait peut-être de l'over-engineering que de créer une classe d'actions pour seulement une ou deux actions.

Voici la classe d'actions associée à cette grammaire :

class CalcActions {
    method TOP ($/) {
        make $<expr>.made
    }
    method expr ($/) {
        $.calculer($/, $<terme>, $<plus-moins-op>)
    }
    method terme ($/) {
        $.calculer($/, $<atome>, $<mult-div-op>)
    }
    method expr-parenth ($/) {
         make $<expr>.made;
    }
    method calculer ($/, $operandes, $operateurs) {
        my $result = (shift $operandes).made;
        while my $op = shift $operateurs {
            my $nombre = (shift $operandes).made;
            given $op {
                when '+' { $result += $nombre; }
                when '-' { $result -= $nombre; }
                when '*' { $result *= $nombre; }
                when '/' { $result /= $nombre; }
                default  { die "operateur inconnu "}
            }
        }
        make $result;
    }
}

La méthode calculer détermine la valeur des expressions (termes séparés par des opérateurs d'addition ou de soustraction) et des termes (atomes séparés par des opérateurs de multiplication ou de division) de gauche à droite, car ces opérateurs sont tous associatifs à gauche.

Cette grammaire et la classe d'actions qui lui est associée peuvent être testées avec le fragment de code suivant :

for |< 3*4 5/6 3+5 74-32 5+7/3 5*3*2 (4*5) (3*2)+5 4+3-1/5 4+(3-1)/4 >,
    "12 + 6 * 5", " 7 + 12 + 23", " 2 + (10 * 4) ", "3 * (7 + 7)" { 
    my $résultat = Calculette.parse($_, :actions(CalcActions));
    # say $résultat;
    printf "%-15s %.3f\n", $/,  $résultat.made if $résultat;
}

Ce qui affiche le résultat suivant :

$ perl6 grammaire_arithm_2.pl6
3*4             12.000
5/6             0.833
3+5             8.000
74-32           42.000
5+7/3           7.333
5*3*2           30.000
(4*5)           20.000
(3*2)+5         11.000
4+3-1/5         6.800
4+(3-1)/4       4.500
12 + 6 * 5      42.000
 7 + 12 + 23    42.000
 2 + (10 * 4)   42.000
3 * (7 + 7)     42.000

On peut se demander si ce programme fonctionne correctement avec des expressions parenthésées imbriquées. Je me suis posé la question quand j'ai écrit ce code, et je pensais qu'il était possible que cela ne fonctionne pas correctement dans ce genre de cas et que j'aurais peut-être des choses à ajouter pour analyser correctement des expressions parenthésées imbriquées. Il s'est trouvé qu'il n'en était rien et que cela fonctionne bien avec des parenthèses imbriquées :

for "(((2+3)*(5-2))-1)*3", "2 * ((4-1)*((3*7) - (5+2)))"  { 
    my $résultat = Calculette.parse($_, :actions(CalcActions));
    printf "%-30s %.3f\n", $/,  $résultat.made if $résultat;
}

Ce qui affiche un résultat correct :

(((2+3)*(5-2))-1)*3            42.000
2 * ((4-1)*((3*7) - (5+2)))    84.000

3-9-1. Composition de rôles▲

role Personne-details {
    has Adresse $.adresse is rw; # Adresse : type défini préalablement
    has NumString $.telephone-fixe is rw;        # idem pour NumString
    method déménage (Adresse $nouvelle-adresse) {
        $.adresse = $nouvelle-adresse;
    }
    # … autres méthodes
}

class Personne-privée does Personne-details {
    has Str $.nom;
    has Str $.prénom;
    # autres attributs et méthodes
}

role Entier {
    token non-signé { <[0..9]>+ }
    token signe { [ '+' | '-' ] }
    token entier-signé { <signe>? <non-signé> }
}

role Flottant does Entier {
    token exposant { :i e \s* <entier-signé> }
    token point-décimal { '.' }
    token nombre-fractionnaire { 
        || <entier-signé> <point-décimal> <entier-signé>
        || <point-décimal> <entier-signé> 
        || <entier-signé> <point-décimal>?
    }
    token flottant { 
        <nombre-fractionnaire> <exposant>?   
    }    
}

grammar MultDiv does Flottant {
    rule TOP {
        || <dividende=nombre> '/' <diviseur=nombre> { 
                make $<dividende> / $<diviseur>
           }
        || [ <nombre> ]+ % \* { make [*] $<nombre> }
        
    }
    token nombre { \s* [<entier-signé> | <flottant> ] \s*}
}
for '7 * 6', '3*2*7', '126/3', '147.0 / 3.5' -> $expr {
    my $match = MultDiv.parse($expr);
    printf "%-20s %s %d \n", $match, "La réponse est: ", $match.made;
}

$ perl6 grammaire_roles.pl6
7 * 6                La réponse est:  42
3*2*7                La réponse est:  42
126/3                La réponse est:  42
147.0 / 3.5          La réponse est:  42

grammar JSON-Grammaire does Flottant {
    token TOP          { ^ \s* [ <objet> | <tableau> ] \s* $ }
    # … Règles définissant les objets, paires, tableaux, chaînes, etc.
    token nombre { <entier-signé> | <flottant> }
    token valeur {
        | <objet> | <tableau> | <chaîne> | <nombre>
        | true    | false     | null 
    }
}

3-9-2. Les règles paramétrées▲

my token date($mois) { \d\d? \s+ $mois \s+ \d**4 }
say "En juin" if "13 juin 2015" ~~ /<date("juin")>/;   # -> En juin
say "En mai"  if "13 juin 2015" ~~ /<date("mai")>/;    # (échec)

my $date = "13 $_ 2015" and say $date ~~ /<date("mai")>/ 
    ?? "Date $date en $_" 
    !! "Date $date pas en $_" 
    for <mars avril mai juin>;
# affiche :
    # Date 13 mars 2015 pas en mars
    # Date 13 avril 2015 pas en avril
    # Date 13 mai 2015 en mai
    # Date 13 juin 2015 pas en juin

my token mots { <[ \w \s \-]>+ }
my token entre-crochets    { <start("[")> <ident> <end("]")> }
my token entre-paren       { <start("(")> <mots>  <end(")")> }
my token entre-chevrons    { <start("<")> <ident> <end(">")> }
my token start($début) { $début }
my token end($fin) { $fin }

say ~$<entre-crochets> if "[Capitaine_Crochet]" ~~ /<entre-crochets>/;
# Affiche : [Capitaine_Crochet]

say $<entre-paren> if "[par-parenthèse]" ~~ /<entre-paren>/;  # -> () 
# (échec puisqu'il y a des crochets et non des parenthèses

say $<entre-paren> if "(par-parenthèse)" ~~ /<entre-paren>/;  
    # Affiche :  
    # ｢(par-parenthèse)｣
    #  start => ｢(｣
    #  mots => ｢par-parenthèse｣
    #  end => ｢)｣

3-9-3. Règles récursives et variables dynamiques▲

grammar G { rule TOP { '(' ~ ')' [ [ $<int>=\d+ ]+| <TOP> ] + } }
say G.parse("(22 (43 45))");
    # Affiche :

    # ｢(22 (43 45))｣
    #  int => ｢22｣
    #  TOP => ｢(43 45)｣
    #   int => ｢43｣
    #   int => ｢45｣

sub fact($n){return 1 if $n <= 1; return $n*fact($n-1)}
sub callfact(Int $n){
    die "Factorielle non définie pour nombre négatif" if $n < 0;
    say "Factorielle = ", fact($n);
}
callfact(5);       # -> 120

sub fact($n){$*sum += $n; return 1 if $n <= 1; return $n*fact($n-1);}
sub callfact(Int $n){
    die "Factorielle non définie pour nombre négatif" if $n < 0;
    my $*sum = 0; 
    say "Fact = ", fact($n); say "Somme = ", $*sum;
}
callfact(5);       # -> Fact = 120 \n Somme = 15

            %*LANG<MAIN>    = ::STD::P6 ;
            %*LANG<Q>       = ::STD::Q ;
            %*LANG<Quasi>   = ::STD::Quasi ;
            %*LANG<Regex>   = ::STD::Regex ;
            %*LANG<P5>      = ::STD5 ;
            %*LANG<P5Regex> = ::STD5::Regex ;

3-9-4. Les règles nommées de type proto▲

proto token sigil {*}
# ...
token sigil:sym<$>  { <sym> }
token sigil:sym<@>  { <sym> }
token sigil:sym<%>  { <sym> }
token sigil:sym<&>  { <sym> }
# ... une petite dizaine d'autres définitions de sigils

token sigil { '$' | '@' | '%' | '&' }

3-9-5. Héritage et grammaires mutables▲

multi sub postfix:<!>(Int $x) {
    my $factorielle = 1;
    $factorielle *= $_ for 2..$x;
    return $factorielle;
}
say 5!;          # -> imprime 120

3-9-6. Modifications de la grammaire et extensibilité du langage▲

grammar NouveauSigilP6 is Perl6 {
    token sigil:sym<µ> { <sym> }
}

grammar EuroPerl6 is Perl6 {
    token sigil:sym<$> { '€' }
}

3-9-7. Perspectives▲

Lorsque l'adverbe :sigspace n'est pas utilisé, les espaces blancs (et les commentaires) sont ignorés dans les regex de Perl 6. Cela offre l'avantage de pouvoir insérer des espaces et des commentaires pour améliorer la lisibilité.

Comparez cette regex très compacte pour reconnaître un nombre à virgule flottante (float) :

my regex float {<[+-]>?\d*'.'\d+[e<[+-]>?\d+]?}

avec celle-ci, équivalente, mais bien plus lisible :

my regex float {
     <[+-]>?            # signe optionnel
     \d*                # chiffres de début, optionnels
     '.'                # séparateur décimal
     \d+
     [                  # exposant optionnel
        e <[+-]>?  \d+
     ]?
}

(L'exemple très simple ci-dessus vise seulement à illustrer le formatage, nous avons donné précédemment de meilleures manières de reconnaître des nombres à virgule flottante. Et nous allons l'améliorer quelque peu plus bas. )

D'une façon générale, il est souhaitable :

• d'utiliser des espaces autour des atomes et à l'intérieur des groupes ;
• de placer les quantificateurs directement après l'atome, sans insérer d'espace, et ;
• d'aligner verticalement les crochets et parenthèses ouvrants ou fermants.

De même, il convient généralement d'aligner les barres verticales «|» séparant les différentes possibilités d'une alternative :

my regex exemple {
    <début>
    [
    || <choix_1>
    || <choix_2>
    || <choix_3>
    ]+
    <fin>
}

Les regex ont besoin de très peu de fioritures ou de code bateau aux alentours, elles sont donc souvent nettement plus compactes que du code ordinaire. Il importe de les garder assez petites.

Quand le nombre de captures devient élevé ou quand on en vient à utiliser des captures nommées pour mieux s'y retrouver, il convient de se demander si l'on ne ferait pas mieux de franchir un pas de plus et de passer à des regex nommées.

4-2-1. Reconnaître un nombre à virgule flottante▲

my token signe { <[+-]> }
my token décimal { \d+ }
my token exposant { 'e' <signe>? <décimal> }
my regex float {
    <signe>?
    <décimal>?
    '.'
    <décimal>
    <exposant>?
}

my regex float {
    <signe>?
    [
    || <décimal>?  '.' <décimal> <exposant>?
    || <décimal> <exposant>
    ]
}

my regex entier {
    <signe>?
    <décimal>
}

4-2-2. Reconnaître un nombre complexe▲

my rule nombre { <float> || <signe>? <décimal> } 
my regex complexe {
    [
    || [<nombre> \s* <signe> \s* ]?  <nombre> \s* 'i'
    || <nombre>
    ]
}
say "Reconnu" if '3+4i' ~~ /<complexe>/;  # -> Reconnu
# Accéder aux différents éléments du nombre complexe reconnu :
say ~$/<complexe> 
     if '3.5e-7 + 4.17i' ~~ /<complexe>/; # 3.5e-7 + 4.17i
say ~$/<complexe><nombre>[0];             # ->  3.5e-7
say ~$/<complexe><nombre>[1];             # ->  4.17
say ~$/<complexe><nombre>[0]<float>       # ->  3.5e-7
say ~$/<complexe><signe>                  # ->  +

4-2-3. Reconnaître une URL▲

4-2-4. Reconnaître une adresse IP▲

/(\d**1..3) \. (\d**1..3) \. (\d**1..3) \. (\d**1..3)/

/ (\d ** 1..3) ** 4 % '.' /

my regex octet { 
                  || (25 <[0..5]>              # 250 à 255
                  || 2 <[0..4]> \d             # 200 à 249
                  || 1 \d**2                   # 100 à 199
                  || \d**1..2)                 # 0 à 99 
}
my regex ip { <octet> ** 4 % '.' }
say "Reconnu" if "244.7.245.23" ~~ /<ip>/;     # -> Reconnu
say ~$/;                                       # -> 244.7.245.23

my regex octet {(\d ** 1..3) <?{0 <= $0 <= 255 }> }

my regex octet { 
                  || (25 <[0..5]>              # 250 à 255
                  || 2 <[0..4]> \d             # 200 à 249
                  || 1\d**2                    # 100 à 199
                  || \d**1..2) <!before \d>)   # 0 à 99 
}
my regex ip { <octet> ** 4 % '.' }

4-2-5. Une grammaire pour reconnaître une URL▲

grammar URL {
    token TOP {
        <schéma> '://' 
        [<ip> | <nom-domaine> ]
        [ ':' <port>]?
        '/' <chemin>?
    }
    token octet {
        (\d**1..3) <?{ $0 < 256 }>
    }
    token ip {
        <octet> [\. <octet> ] ** 3
    }
    token schéma {
        \w+       # Ce pourrait aussi être : [http | https | ftp | ...]
    }
    token nom-domaine {
        (\w+) ( \. \w+ )*
    }
    token port {
        \d+
    }
    token chemin {
        <[ a..z A..Z 0..9 \-_.!~*'():@&=+$,/ ]>+
    }
}

my $cible = URL.parse('http://perl6.org/documentation/');
say $cible<nom-domaine>;       # -> perl6.org

Souvent, le format des données en entrée n'est pas clairement spécifié, ou la spécification, si elle existe, n'est pas connue du programmeur. Il est alors souvent utile d'être assez libéral ou souple sur ce que l'on attend, mais seulement dans la mesure où il n'y a pas de risque d'ambiguïté.

Si l'on reprend l'exemple du fichier .ini :

[section]
key=value

Que peut-il y avoir dans l'entête de section ? N'autoriser qu'un seul mot est peut-être trop restrictif, peut-être quelqu'un va écrire [deux mots], ou utiliser des tirets, ou Dieu seul sait quoi d'autre… Plutôt que se demander ce qui est autorisé à l'intérieur de cet entête, il peut être utile de se demander ce qui n'est pas permis.

Clairement, un crochet fermant est interdit, parce que [a]b] serait pour le moins ambigu. Du même point de vue, un crochet ouvrant doit être proscrit. Ce qui peut nous donner la règle suivante :

token entête { '[' <-[ \[\] ]>+ ']' }

ce qui semble bien fonctionner si l'on analyse une seule ligne. Mais si l'on traite un fichier entier, soudain la règle analyse :

[ avec un
retour à la ligne entre deux]

comme un entête correct, ce qui n'est sans doute pas une bonne idée. Un compromis pragmatique pourrait être d'écrire :

token entête { '[' <-[ \[\] \n ]>+ ']' }

puis, dans le post-traitement, d'éliminer les espaces, tabulations, etc. au début et à la fin de l'entête de section.

L'adverbe :sigspace (ou l'utilisation d'une règle de type rule, plutôt que regex ou token) est très pratique pour l'analyse d'espaces qui peuvent apparaître en de multiples endroits.

Si l'on revient à l'exemple d'analyse de fichiers ini, la règle peut être la suivante :

my regex kvpair { \s* <clef=identifiant> '=' <val=identifiant> \n+ }

Cela fonctionne en principe, mais n'est peut-être pas aussi flexible qu'on pourrait le désirer. Comme l'utilisateur peut décider de mettre des espaces autour du signe égal, peut-être faudrait-il plutôt :

my regex kvpair { \s* <clef=identifiant> \s* '=' \s* <val=identifiant> \n+ }

Cela peut rapidement devenir peu pratique. On pourrait donc tenter d'utiliser une rule au lieu d'une regex et d'écrire :

my rule kvpair { <clef=identifiant> '=' <val=identifiant> \n+ }

Mais attention ! La reconnaissance implicite des espaces après la valeur consomme tous les espaces disponibles, y compris les caractères de retour à la ligne, si bien que le \n+ final n'a plus rien à reconnaître. Et comme une rule désactive le retour arrière, cela ne marche pas.

C'est là qu'il peut être fort utile de redéfinir l'espace implicite comme un espace qui n'est pas significatif dans le format en entrée, ce que l'on peut faire en redéfinissant le token ws (mais cela ne fonctionne qu'à l'intérieur de grammaires) :

grammar IniFormat {
    token ws { <!ww> \h* }
    rule entête { '[' (\w+) ']' \n+ }
    token identifiant  { \w+ }
    rule kvpair { \s* <clef=identifiant> '=' <val=identifiant> \n+ }
    token section {
        <entête>
        <kvpair>*
    }

    token TOP {
        <section>*
    }
}

# Exemple de fichier ini dans un document "ici même" :
my $contenu = q:to/FIN_INI/;
    [passwords]
        jean=mdp1
        anne=plusfiable123
    [quotas]
        jean=123
        anne=42
FIN_INI

say so IniFormat.parse($contenu);

Outre l'idée de mettre toutes les regex dans une grammaire et de les transformer en tokens ou rules (car ces regex n'ont pas besoin de retour arrière de toute façon), le point intéressant et nouveau est la définition suivante :

token ws { <!ww> \h* }

qui est appelée lors de l'analyse implicite des espaces. Il reconnaît zéro ou plusieurs espaces horizontaux qui ne sont pas entre deux caractères de type mot (<!ww>, négation de l'assertion « within word »). La limitation à des espaces horizontaux est essentielle, parce que les caractères de retour à la ligne (qui sont des espaces verticaux) délimitent les enregistrements et ne doivent donc pas être reconnus implicitement comme simples espaces.

Il peut encore y avoir un problème lié aux espaces au détour du chemin. Le regex \n+ ne va pas reconnaître une chaîne telle que \n \n, parce qu'il existe un espace entre les deux retours à la ligne. Pour reconnaître ce genre de chaînes en entrée, il est possible de remplacer \n+ par \n\s*.

On appelle récursion gauche (ou récursion à gauche) une situation dans laquelle une grammaire peut entrer dans une récursion infinie si une règle s'appelle elle-même en début de motif et ne consomme pas nécessairement de caractères de la chaîne analysée (par exemple en raison d'un quantificateur comme ? ou * autorisant la reconnaissance d'une chaîne vide).

Considérons par exemple la règle suivante :

token x { <x>? 'x' }

On pourrait penser que cette règle est équivalente au motif x+, mais il n'en est rien et cette règle va entrer dans une récursion infinie parce que le quantificateur ? lui permet de reconnaître une chaîne vide et ne consomme alors aucun élément de la chaîne analysée, tout en s'appelant récursivement.

Pour éviter ce piège, vous devez vous assurer que chaque appel récursif fait avancer le curseur du moteur de regex d'au moins un caractère.

Une situation de récursion gauche peut également se produire en cas de récursion indirecte : par exemple si la règle <A> appelle la règle <B>, qui appelle elle-même la règle <C>, et que la règle <C> appelle à son tour la règle <A> : s'il peut arriver pour certaines chaînes de caractères qu'aucune des trois règles ne consomme de caractère, alors on risque à nouveau d'entrer dans un cycle de récursion infini. Là encore, la parade est de garantir qu'une au moins de ces trois règles consomme au moins un caractère de la chaîne.

La grammaire de la calculette de la section 3.8. présente ce genre de récursion indirecte. : on peut par exemple se trouver avec la succession suivante d'appels de règles :

TOP → expr → terme → atome → expr-parenth → expr …

dans laquelle la règle expr s'appelle elle-même indirectement.

Mais il n'y a aucun risque de récursion infinie dans cette grammaire parce que l'une des règles de cette chaîne de récursion consomme au moins un caractère de la chaîne analysée avant de pouvoir appeler la suivante ; plus précisément, la règle expr-parenth :

rule expr-parenth     { '(' <expr> ')' }

doit consommer une parenthèse ouvrante de la chaîne de caractère analysée avant d'appeler récursivement expr.

Quand on commence à apprendre à programmer, on perd beaucoup de temps avec de petites erreurs stupides. Avec l'expérience, on apprend à faire moins d'erreurs et à écrire plus rapidement du code qui fonctionne.

Avec les grammaires (et plus généralement les regex), tout semble recommencer comme au début : même des programmeurs expérimentés recommencent à faire des erreurs stupides quand il s'attaquent aux grammaires. Écrire une regex et plus encore une grammaire n'a pas grand-chose à voir avec le développement d'un programme procédural ordinaire et nécessite une nouvelle phase d'apprentissage.

Voici quelques pistes pour aider à écrire et déboguer des grammaires (qui rejoignent en partie certains conseils déjà donnés ci-dessus) :

• avancez par petites étapes, règle par règle, et testez les règles au fur et à mesure ;

• testez les règles individuellement : si votre grammaire ne fonctionne pas, testez chaque règle une par une afin de déterminer si une règle est erronée, mal appelée (ou jamais appelée), etc. :

   

  Sélectionnez

  grammar MaGrammaire {
      token TOP {
          ^ [ <commentaire> | <truc> ]* $
      }
  
      token commentaire {
          '#' \N* $$
      }
      token truc {
          ^^(\S+) \= (\S+) $$
      }
  }
  
  # Essayer de parser l'ensemble:
  say ?MaGrammaire.parse("#commentaire\ntoto = titi");       # 0
  # La grammaire ne reconnaît pas le test, voyons les règles une à une
  say ?MaGrammaire.parse("#commentaire\n", :rule<commentaire>); # 1 - OK
  say ?MaGrammaire.parse("toto = titi", :rule<truc>);           # 0 - KO
  # C'est la règle <truc> qui ne fonctionne pas.

• insérez des affichages (print ou say) ; il suffit de les mettre entre des accolades pour que ces affichages s'exécutent comme du code ordinaire (voir § 3.4.2.). Reprenons l'exemple précédent là où nous étions arrivés (la règle <truc> ne fonctionne pas) :

   

  Sélectionnez

  grammar MaGrammaire {
      token truc {
          { say "truc: appelé" }
          ^^
          { say "truc: trouvé début de ligne" }
          (\S+) 
          { say "truc: trouvé premier identifiant: $0" }
          \= 
          { say "truc: trouvé =" }
          (\S+) $$
      }
  }
  
  say ?MaGrammaire.parse("toto = titi", :rule<truc>);
  
  # Affichage:
  #
  # truc: appelé
  # truc: trouvé début de ligne
  # truc: trouvé premier identifiant: toto
  # 0
  # C'est le signe égal qui n'est pas reconnu. Pourquoi? À cause
  # de l'espace qui le précède et qui n'est pas dans la règle. Il
  # suffit par exemple de transformer le token en rule

• Attention au contrôle du retour arrière : beaucoup de programmeurs habitués à Perl 5 ou à des systèmes de regex apparentés sont rompus à l'utilisation du retour arrière, très naturelle et très puissante dans de simples regex de petite dimension. Mais le retour arrière devient très vite difficile à maîtriser dans une grammaire (ou même un ensemble de regex) imbriquée. La plupart des problèmes d'analyse lexicale et syntaxique peuvent se formuler d'une façon qui ne nécessite pas (ou très peu) de retour arrière, et il est donc fortement recommandé d'éviter le retour arrière dans les grammaires, aussi bien pour des raisons d'efficacité que par mesure de sauvegarde de la santé mentale du développeur. Cela dit, certains motifs sont bien plus faciles à écrire avec du retour arrière ; si vous les utilisez, veillez à en limiter la portée à la seule regex en ayant besoin, soit en définissant une sous-regex séparée pour la seule partie nécessitant le retour arrière, soit en utilisant une règle de type rule ou token n'autorisant pas le retour arrière et en l'autorisant pour la seule partie en ayant besoin :

   

  Sélectionnez

  rule verbatim {
      '[%' ~ '%]' verbatim
      # Autorise le retour arrière à partir d'ici seulement
      :!ratchet
      .*? '[%' endverbatim '%]'
  }
  # Le retour arrière sera activé dans la regex finale, mais, dès 
  # qu'une reconnaissance aura été trouvée, on n'en essaiera pas d'autre

• Signalons enfin l'excellent module de débogage de grammaires et de regex de Jonathan Worthington sous Rakudo/Perl 6. Ajoutez un useRegex::Tracer; dans votre code, et toutes vos grammaires dans la portée lexicale afficheront en couleur des informations de débogage détaillées, montrant notamment quelles règles ont été appelées, lesquelles ont fonctionné et lesquelles ont échoué. Le Calendrier de l'Avent Perl 6 donne des exemples et plus de détails.

Les informations de la présente section 4.6 Déboguer des regex ou des grammaires Perl 6 sont empruntées pour l'essentiel au document How to Debug a Perl 6 Grammar de Moritz Lenz.