Lines Matching full:nous
22 <strong>problème</strong>. Et des problèmes, il en existe beaucoup. Nous
30 bien comprendre tous ces concepts. Toutefois, nous allons essayer de
39 petite <strong>unité lexicale</strong> d'un langage, il est atomique et nous
42 <strong>règles</strong>. À partir d'un mot et d'une règle racine, nous allons
45 considéré comme <strong>invalide</strong>. Nous parlons aussi de
46 <strong>reconnaissance</strong> de mots. Par exemple, si nous considérons les
53 <p>Le mot que nous voulons reconnaître est <code>7 + 35</code>. La règle
54 racine est <code><em>exp</em></code>. Si nous la dérivons (de gauche à droite
56 <em lang="en">top-to-bottom</em> en anglais), nous pouvons avoir
65 <p>Nous continuons à dériver jusqu'à <strong>éliminer</strong> toutes les
150 <code>Hoa\Compiler</code> : LL(1) et LL(*). D'une manière générale, nous
153 <strong>revenir</strong> jusqu'à <em>k</em> étapes en arrière ; nous parlons
155 <strong>ambiguës</strong> : à chaque fois que nous dérivons une règle de la
156 grammaire, nous avons plusieurs choix possibles et l'analyseur peut se
161 règles, il n'y a qu'un seul choix possible. Et si nous avons un analyseur
171 <p>Voyons quand nous essayons de trouver une dérivation pour le mot
225 <p>Pour expliquer les règles, nous allons utiliser comme exemple la grammaire
269 <p>Nous remarquons que nous avons deux espaces de noms pour les lexèmes :
272 <code>string:_quote</code> qui ont la même représentation). Nous remarquons
330 <p>Si l'analyse syntaxique est un succès, nous obtenons une
333 textuelle après analyse. Il a l'avantage de pouvoir être visité (nous
341 compilateur, nous allons appeler la méthode
343 la donnée est correcte, nous aurons en retour un AST, sinon une exception sera
344 levée. Enfin, nous allons utiliser le visiteur
368 <p>Quand nous écrivons et testons une grammaire, nous allons répéter ces trois
388 <p>Les analyses s'effectuent sur la règle <strong>racine</strong> mais nous
394 valide ou pas, nous pouvons utiliser le dernier argument de notre méthode en
449 si nous remplaçons la règle <code>array</code> par :</p>
476 l'analyse lexicale, grâce à l'opérateur <code>-></code>. Ainsi, nous allons
537 <p>Nous lisons les lexèmes, leur espace et leur valeur dans le tableau. La
538 donnée a pu être <strong>découpée</strong>, et nous sommes passés d'un espace
539 à un autre. Si cette fois nous essayons avec la donnée <code>foqux</code>,
540 nous aurons une erreur : <code>fo</code> correspond au lexème <code>foo</code>
541 dans l'espace <code>default</code>, nous changeons alors d'espace pour
544 <p>Jusqu'à maintenant, nous avons vu comment passer d'un espace à l'autre avec
548 et que nous aimerions qu'un lexème déclenche le retour vers l'espace de noms
549 <strong>précédent</strong>. Autrement dit, nous aimerions un historique des
615 <p>Nous voyons que l'analyse lexicale a réussi à jongler avec les espaces de
616 noms, comme attendu. Nous avions deux façons d'accéder à l'espace
675 <code>Hoa\Compiler\Llk\TreeNode</code>. Parmis les méthodes utiles, nous
692 <strong>parcourir</strong> un AST. En guise d'exemple, nous allons écrire le
783 <p>Nous allons voir tout de suite un exemple d'utilisation :</p>
816 <strong>trivial</strong> et nous l'utiliserons la plupart du temps avec un
853 <p>Nous pouvons l'obtenir grâce à la méthode
855 trace, nous allons commencer par un exemple :</p>
922 <p>Cet exemple nous révèle plusieurs choses. Tout d'abord, les informations
923 que nous donne la trace peuvent être utiles : si nous sommes sur une règle,
924 nous avons son <strong>nom</strong> (avec la méthode <code>getRule</code>), et
925 si nous sommes sur un lexème, nous avons son <strong>nom</strong> (avec la
934 <p>Ensuite, nous remarquons que parfois nous entrons dans une règle qui existe
936 <code>value</code> etc., et parfois nous entrons dans une règle
951 Nous allons afficher toutes les règles <strong>accessibles</strong> depuis la
1014 <p>Si nous lisons la règle <code>object</code>, nous savons que c'est la
1023 nous pouvons déjà effectuer des traitements.</p>
1028 <strong>valider</strong> une donnée (si nous la voyons comme un automate) ou
1029 <strong>générer</strong> des données. Jusqu'à présent, nous avons vu comment
1034 <strong>AST</strong> pour enfin <strong>visiter</strong> cet arbre. Mais nous
1035 pouvons nous arrêter à la première étape, la préparation de notre compilateur,
1047 d'utilisations. Chacun répond à des besoins différents, nous l'expliquerons
1063 doit être <strong>rapide</strong>. Nous allons utiliser un parcours dit
1064 <strong>isotrope</strong>. Nous partons d'une règle et nous avançons
1066 localement</strong> (uniquement pour ce choix). Par exemple si nous avons une
1067 disjonction entre trois sous-règles, nous allons tirer aléatoirement et
1068 uniformément entre 1 et 3. Si nous avons une concaténation, nous allons juste
1089 et <strong>uniforme</strong>. Cet algorithme est utile si nous voulons générer
1100 <p>Nous allons générer 10 données aléatoires de taille 7, c'est à dire
1101 composées de 7 lexèmes. Pour cela, nous allons utiliser la classe
1131 <p>Nous pouvons redéfinir la taille avec la méthode
1132 <code>Hoa\Compiler\Llk\Sampler\Uniform::setLength</code>. Nous aurons
1134 supérieures, comme <code>+</code> ou <code>*</code> ; dans ce cas, nous la
1187 <p><em>A l'instar</em> de l'algorithme précédent, nous pouvons redéfinir la
1225 <strong>termination</strong> de l'algorithme, nous utilisons
1233 <p>Nous remarquons dans notre exemple que 4 données sont générées et suffisent