Ce sujet fait suite aux sujets suivants, qui ont vu le jour dans le laboratoire il y a déjà quelques temps :
Proposition d'une grammaire formelle, par Phlogistique : http://thefpsb.penspinning.fr/viewtopic.php?f=67&t=3744
Applications de l'analyse formelle des combos, par Zombo : http://thefpsb.penspinning.fr/viewtopic.php?f=67&t=3712
Le but de ce post est de mettre les notions de grammaire formelle et de langage des breakdowns accessible à un maximum de monde. Cela prend donc la forme d'un tutorial pour comprendre une grammaire et construire sa propre grammaire.
I - INTRODUCTION
Les applications des grammaires formelles dépassent de loin le domaine du penspinning, qui n'en est absolument pas la source. La théorie des langages qui englobe la théorie des grammaires s'est développée avec le développement de l'informatique, et actuellement tout le monde de la programmation repose sur ces principes.
I.1 Qu'est-ce qu'une grammaire formelle ?
Pour faire simple, une grammaire formelle est un ensemble de règles permettant de définir, pour un ensemble de mots donnés, les combinaisons de ces mots acceptables ou non. C'est une formalisation du concept très commun de grammaire pour les langages parlés ou écrits dans le monde entier.
I.2 Trois niveaux d'analyse
Comme on l'a vu plus haut, l'analyse grammaticale consiste à vérifier si une phrase donnée respecte les règles d'une grammaire donnée. Mais enfin, avant de vérifier si la phrase suit la grammaire, il est évident que si elle utilise des mots inconnus à la langue française, elle sera incorrecte !
- l'analyse lexicale : vérifier que tous les mots (aussi appelés "lexêmes") utilisés sont bien dans le lexique du langage. L'exemple 2 correspond à ce type d'analyse.
- l'analyse syntaxique : vérifier que les mots sont bien agencés selon les règles de syntaxe du langage. l'exemple 1 correspond à ce type d'analyse.
Enfin pour parachever l'analyse, il existe un troisième niveau, appelé "analyse sémantique". Son but est de donner un sens à la phrase si cela est possible, et si ça ne l'est pas, de la déclarer invalide, de la même manière que dans les analyses précédentes.
En pratique, dans la plupart des langages de programmation, on s'arrange pour qu'un maximum des expressions grammaticalement correctes aient un sens, et soient donc valides. Cependant, rien ne garantit qu'un programme informatique produise bien les actions que vous souhaitiez, même si votre programme est grammaticalement correct... C'est donc au programmeur essentiellement de donner un sens bien défini à son programme.
Dans la suite de cet exposé, on s'attachera à décrire les notions de lexique, de grammaire, en donnant quelques exemples au fur et à mesure. On laissera un peu de côté l'aspect sémantique, qui comme je l'ai dit est la tâche du programmeur. Donner des exemples dans ce domaine nécessiterait de vous fournir des connaissances élémentaires en programmation et en algorithmique, et ce n'est pas mon but ici.
J'espère cependant qu'à la fin de votre lecture de cet article, vous serez capable d'écrire votre propre grammaire, pour un petit langage simple de votre choix.
I.1 Qu'est-ce qu'une grammaire formelle ?
Pour faire simple, une grammaire formelle est un ensemble de règles permettant de définir, pour un ensemble de mots donnés, les combinaisons de ces mots acceptables ou non. C'est une formalisation du concept très commun de grammaire pour les langages parlés ou écrits dans le monde entier.
Il en va de même pour les langages informatiques. Sauf que bien souvent, les règles des grammaires de langage informatique sont moins complexes que celles du français ! Il faut en effet qu'elle soient accessibles à une machine procédant de manière automatique, et donc moins "intelligente" qu'un être humain doté de réflexion. C'est d'ailleurs à cause de ces limitations qu'actuellement, les fonctions de correction automatique des logiciels ne sont pas capables de détecter toutes les erreurs de grammaire dans une phrase typographiée.Exemple 1 : En français, la phrase Je suis avec vous . est correcte. En revanche, Je vous avec suis. est grammaticalement incorrecte. Vous allez me dire, elle n'a aucun sens. Certes, mais avant même d'en chercher le sens, le lecteur francophone sait que la phrase est incorrecte. Cela tient du fait que notre esprit a été éduqué (ou pas...) pour respecter une grammaire bien précise, celle du français.
I.2 Trois niveaux d'analyse
Comme on l'a vu plus haut, l'analyse grammaticale consiste à vérifier si une phrase donnée respecte les règles d'une grammaire donnée. Mais enfin, avant de vérifier si la phrase suit la grammaire, il est évident que si elle utilise des mots inconnus à la langue française, elle sera incorrecte !
Pour l'analyse grammaticale d'une "phrase" dans un "langage", il existe en fait deux niveaux d'analyse, classés ci-dessous par ordre de priorité décroissante :Exemples 2 :
la phrase Je suis avec vous. est correcte selon le lexique de la langue française. Elle est également grammaticalement correcte.
la phrase I am avec vous. est incorrecte : son lexique n'est pas celui de la langue française ! Néanmoins, si l'on utilisait un langage réunissant les entités grammaticales françaises et anglaises, avec des règles communes, le lexique correspondrait et elle serait alors grammaticalement correcte...
- l'analyse lexicale : vérifier que tous les mots (aussi appelés "lexêmes") utilisés sont bien dans le lexique du langage. L'exemple 2 correspond à ce type d'analyse.
- l'analyse syntaxique : vérifier que les mots sont bien agencés selon les règles de syntaxe du langage. l'exemple 1 correspond à ce type d'analyse.
Enfin pour parachever l'analyse, il existe un troisième niveau, appelé "analyse sémantique". Son but est de donner un sens à la phrase si cela est possible, et si ça ne l'est pas, de la déclarer invalide, de la même manière que dans les analyses précédentes.
L'analyse sémantique est une tâche sans doute impossible à automatiser pour les langages humains, en revanche pour des langages informatiques elle est possible, et c'est même la pierre angulaire des langages de programmation !Exemple 3 :
- la phrase Je suis avec vous. est sémanticalement correcte en français, son sens est clair pour un lecteur francophone.
la phrase Je suis le sable avec vous. est difficilement compréhensible, bien qu'aucune régle lexicale ou grammaticale ne l'invalide !
En pratique, dans la plupart des langages de programmation, on s'arrange pour qu'un maximum des expressions grammaticalement correctes aient un sens, et soient donc valides. Cependant, rien ne garantit qu'un programme informatique produise bien les actions que vous souhaitiez, même si votre programme est grammaticalement correct... C'est donc au programmeur essentiellement de donner un sens bien défini à son programme.
Dans la suite de cet exposé, on s'attachera à décrire les notions de lexique, de grammaire, en donnant quelques exemples au fur et à mesure. On laissera un peu de côté l'aspect sémantique, qui comme je l'ai dit est la tâche du programmeur. Donner des exemples dans ce domaine nécessiterait de vous fournir des connaissances élémentaires en programmation et en algorithmique, et ce n'est pas mon but ici.
J'espère cependant qu'à la fin de votre lecture de cet article, vous serez capable d'écrire votre propre grammaire, pour un petit langage simple de votre choix.
La définition d'un lexique fait partie intégrante de la définition d'une grammaire. Différentes notations existent, j'en utiliserai une assez commune, cependant, d'un langage un autre, le mode de définition peut varier assez fortement. Pour un exemple de définition assez différente, ou syntaxe et lexique sont définies d'un même coup, le topic de Phlogistique est un bon exemple. Voici le mien :
II.1 Enumération lexicale.
Le principe de lecture est le suivant :
- les termes en lettres capitales représentent des "symboles terminaux", c'est-à-dire des entités grammaticales indivisibles.
- Ces entités peuvent elle-mêmes prendre différentes valeurs de texte,définies entre "", et appelées lexêmes ici en lettres minuscules. C'est donc un moyen de regrouper différents mots acceptables dans des ensembles de mots dont les fonctions grammaticales seront ensuite définies.
----> Ex : la lecture textuelle des lexêmes "chien" ou "chat" correspond, dans un cas ou dans l'autre, à la lecture du symbole terminal NOM.
----> Ex : le symbole LIAISON_POSSESSION ne peut avoir comme valeur textuelle que "de" ou "appartenant à".
- Il est très important de ne pas faire n'importe quoi avec les lexêmes et les symboles terminaux, que cela colle à l'utilisation par la grammaire.
- Dans ce premier exemple, on a plus ou moins fait correspondra nos lexêmes aux entités lexicales de la langue française, pour une compréhension plus intuitive.
- la définition d'un symbole terminal ( ici, une ligne de notre lexique ) est une règle grammaticale à part entière.
>>>Qu'est-ce que ça donne sur du penspinning ?
>>> Que donne une analyse avec ce lexique ?
II.2 Expressions régulières.
L'énumération de tous les éléments représentables par un lexême posent des difficultés, notamment dans le cas où il y en a une infinité ! Par exemple, dans le cadre de notre lexique L2, SPIN_MODIFIER est limité aux valeurs "1.0", "1.5" et "2.0", alors qu'on peut potentiellement imaginer des spins de "n.0" ou "n.5", avec n arbitrairement grand... Il existe une solution magique pour ce genre de problèmes, incarnée par les expressions régulières.
Le concept d'expression régulière est utilisé par de nombreux langages informatiques, et en théorie informatique également. Il est d'ailleurs à l'origine de la théorie des langages elle-même, ce n'est pas peu dire. Voici une défintion très simplifiée des expressions régulières :
Définition : Une expression régulière est un mot, constitué d'opérateurs et de valeurs lexicales, définissant un ensemble de mots.
Attention cependant, tout ensemble de mots quelconque n'est pas forcément définissable par une expression régulière...
Par exemple, définissons les opérations suivantes :
Notons que peut-être serons-nous amenés, lors de la création de notre langage du penspinning, à créer notre propre syntaxe pour les expressions régulières ... Oui parce que d'une certaine manière, c'est déjà un langage à part entière, avec une grammaire, un lexique et tout et tout ^^ !
II.1 Enumération lexicale.
>>> Comment décrypter ce lexique ?Exemple 5 : un lexique L1 pour les groupes nominaux en français approximatif
NOM : "oiseau" | "chien" | "chat" | "voisin" | "maman"
-----------------------------
PRONOM : "le" | "la" | "un" | "une" | "ce" | "mon" | "ma"
-----------------------------
ADJECTIF : "vert" | "grand" | "décadent" | "intranscriptible"
-----------------------------
CONJONCTION_COORDINATION : "et" | "ou"
-----------------------------
LIAISON_POSSESSION : "de" | "appartenant à"
-----------------------------
Le principe de lecture est le suivant :
- les termes en lettres capitales représentent des "symboles terminaux", c'est-à-dire des entités grammaticales indivisibles.
- Ces entités peuvent elle-mêmes prendre différentes valeurs de texte,définies entre "", et appelées lexêmes ici en lettres minuscules. C'est donc un moyen de regrouper différents mots acceptables dans des ensembles de mots dont les fonctions grammaticales seront ensuite définies.
----> Ex : la lecture textuelle des lexêmes "chien" ou "chat" correspond, dans un cas ou dans l'autre, à la lecture du symbole terminal NOM.
----> Ex : le symbole LIAISON_POSSESSION ne peut avoir comme valeur textuelle que "de" ou "appartenant à".
- Il est très important de ne pas faire n'importe quoi avec les lexêmes et les symboles terminaux, que cela colle à l'utilisation par la grammaire.
- Dans ce premier exemple, on a plus ou moins fait correspondra nos lexêmes aux entités lexicales de la langue française, pour une compréhension plus intuitive.
- la définition d'un symbole terminal ( ici, une ligne de notre lexique ) est une règle grammaticale à part entière.
>>>Qu'est-ce que ça donne sur du penspinning ?
Je vous laisse la primeure de décrypter ce lexique, qui n'est qu'une base extrêmement simplifiée pour une description des combos utilisant uniquement des dérivés de tricks "fondamentaux".Exemple 5 : un lexique L2 pour les combos de fondamentaux
TRICK_NAME : "sonic" | "backaround" | "thumbaround" | "charge" | "infinity"
-----------------------------
STYLE_MODIFIER : "fingerless" | "aerial"
-----------------------------
SPIN_MODIFIER : "1.0" | "1.5" | "2.0"
-----------------------------
DIRECTION_MODIFIER : "reverse" | "normal"
-----------------------------
LINK_WORD : ">"
-----------------------------
>>> Que donne une analyse avec ce lexique ?
On voit donc bien à ce stade qu'une analyse lexicale est loin de satisfaire tous nos besoins. Il est donc nécessaire de définir des règles supplémentaires, que l'on va présenter plus tard comme les règles syntaxiques qui doivent régir notre langage des combos.Exemple 6 : Analyse de phrases à l'aide du lexique L2.
sonic > backaround > fingerless thumbaround 1.5 > aerial infinity ____ lexicalement correct.
sonic backaround fingerless > > > 1.5 aerial >> 2.0 1.0 reverse > ____ lexicalement correct !
sonic x 3 > backaround ~> TA _______________________________ lexicalement incorrect. Certains termes ne sont pas définis dans le lexique L2.
II.2 Expressions régulières.
L'énumération de tous les éléments représentables par un lexême posent des difficultés, notamment dans le cas où il y en a une infinité ! Par exemple, dans le cadre de notre lexique L2, SPIN_MODIFIER est limité aux valeurs "1.0", "1.5" et "2.0", alors qu'on peut potentiellement imaginer des spins de "n.0" ou "n.5", avec n arbitrairement grand... Il existe une solution magique pour ce genre de problèmes, incarnée par les expressions régulières.
Le concept d'expression régulière est utilisé par de nombreux langages informatiques, et en théorie informatique également. Il est d'ailleurs à l'origine de la théorie des langages elle-même, ce n'est pas peu dire. Voici une défintion très simplifiée des expressions régulières :
Définition : Une expression régulière est un mot, constitué d'opérateurs et de valeurs lexicales, définissant un ensemble de mots.
Attention cependant, tout ensemble de mots quelconque n'est pas forcément définissable par une expression régulière...
Par exemple, définissons les opérations suivantes :
opérateur * : l'étoile représente la répétition un nombre arbitrairement grand de fois d'une lettre ou d'un mot, éventuellement zéro fois.
Ex : "a"* représente l'ensemble des mots "", "a", "aa", "aaa", "aaaa", etc.
Ex : "abc"* représente l'ensemble des mots "", "abc", "abcabc", "abcabcabc", "abcabcabcabc", etc.
opérateur + : le symbole "+" représente le "ou" logique sur des lettres ou mots.
Ex : "a"+"b" représente l'ensemble des mots "a" et "b".
Ex : "a"* + "b"* représente l'ensemble des mots "", "a", "aa", "aa", ... , "b", "bb", "bbb", ...
opérateur . : le symbole "." représente la concaténation des lettres ou mots, c'est-à-dire leur mise bout à bout.
Ex : "a".("b"*) représente l'ensemble des mots "a" et "ab", "abb", "abbb"...
Ex : "a"*.("b"*+"c") représente l'ensemble des mots "c", "ac", "aac", "aaac" ... mais aussi des mots "b", "bb", "bbb", ... et également "ab", "aabbb", "aaaaaab" , "aaaaaaaaaaaa" ...
Et voilà, grâce à des opérateurs et des mots de base, on a défini des mini-langages pour décrire les mots eux-mêmes ! On peut donc améliorer notre lexique de base pour y intégrer tous les SPIN_MODIFIER couramment utilisés :opérateur [] : les crochets représentent un moyen raccourci de représenter des mots contenant un ensemble de sous-mots ou de lettres :
Ex : [abc] représente tous les mots qui ne contiennent que les lettres a, b, ou c, et au moins une lettre ("a", "b", "c", "aabccabc", "bba", etc )
Ex : ["moi""toi""lui""elle"UVW] représente tous les mots "moi", "toiU" "UVelleWlui", "toitoimoielleWW", etc ...
Ex : [0123456789] . "." . [05] représente l'ensemble des nombres de type "n.0" ou "n.5", avec n positif ou nul ! ("0.5", "1.5", "23.0", "35.5", "1024.0", etc)
ATTENTION : notez bien que mes opérateurs sont couramment utilisés, mais pas les symboles qui les représentent ! Chaque langage informatique possède sa propre syntaxe pour les expressions régulières, avec parfois des opérateurs supplémentaires, et des symboles différents pour les représenter... Ceci est une simple introduction au concept, pas un manuel d'utilisation universel !Exemple 7 : un lexique L2.1 pour les combos de fondamentaux
TRICK_NAME : "sonic" | "backaround" | "thumbaround" | "charge" | "infinity"
-----------------------------
STYLE_MODIFIER : "fingerless" | "aerial"
-----------------------------
SPIN_MODIFIER : [0123456789] . "." . [05]
-----------------------------
DIRECTION_MODIFIER : "reverse" | "normal"
-----------------------------
LINK_WORD : ">"
-----------------------------
Notons que peut-être serons-nous amenés, lors de la création de notre langage du penspinning, à créer notre propre syntaxe pour les expressions régulières ... Oui parce que d'une certaine manière, c'est déjà un langage à part entière, avec une grammaire, un lexique et tout et tout ^^ !
Bon ça y est, on a un petit lexique certes rudimentaire, mais potable. Et maintenant, que peut-on en faire ? Et bien comme on l'a vu, ces règles ne suffisent pas à sélectionner les combos corrects, il faut donc franchir une étape supplémentaire, et définir des règles pour agencer tous ces lexêmes entre eux. Allez, on tente le coup.
III.1 Définition des règles de syntaxe.
Oui, là ça se complique. Plusieurs choses sont à noter :
- On ne définit plus des symboles terminaux, en revanche on les utilise.
- Les nouveaux symboles définis, et écrits ici en minuscule, sont des "symboles non-terminaux", tout simplement parce qu'ils sont eux-mêmes décomposables en zéro, un, ou plusieurs symboles terminaux.
- Et mieux, un symbole non-terminal peut être décomposé en une association de symboles terminaux mais aussi non-terminaux !
On tente ici une description pas à pas de notre grammaire :
un combo est représenté :
* soit par un trick, sur lequel on enchaine, grâce à un symbole de liaison, par un autre combo.
* soit par un combo sur lequel on enchaine, grâce à un symbole de liaison, par un autre combo.
* soit par un simple trick unique. Un combo hyper court, d'un seul trick.
* on refuse ici le concept de "combo vide" qui serait en fait ne rien faire. Si on l'avait accepté, un combo pourrait commencer par zéro trick puis un symbole de liaison, ce qui est un peu moche !
un trick est représenté :
* par un symbole contenant les modificateurs de style (trick_style_mods)
* suivis du symbole modificateur de direction (trick_direction_mods)
* suivis d'un nom de trick (TRICK_NAME)
* suivi de modificateurs de spin (trick_spin_mod)
un trick_style_mods est représenté :
* par un STYLE_MODIFIER suivi d'un autre trick_style_mods
* ou bien par rien du tout.
---> On peut donc discerner le principe : il peut y avoir un STYLE_MODIFIER suivi de rien du tout, ou bien plusieurs STYLE_MODIFIER d'affilée ! Ce principe de définition s'appelle la "récursivité", on y renviendra à la fin de cette partie pour ceux que ça intéresse.
Je vous laisse réfléchir 2 secondes pour comprendre la définition de trick_spin_mod et trick_direction_mod ! Elles différent de celle de trick_style_mods par le fait que cette fois-ci, on n'aura qu'un seul symbole terminal, ou bien rien du tout...
III.2 Analyse "automatique" d'un breakdown.
>>> Et l'analyse elle donne quoi du coup ?
Et bien testons sur quelques exemples, une analyse "automatique" de quelques breakdowns :
En revanche, si vous lui donnez sonic > fingerless reverse thumbaround 1.5, comment finit-elle le job ? Reprenons juste avant l'erreur ...
III.3 Récursivité
Certains l'auront remarqué, les définitions lors des règles syntaxiques utilisent un procédé assez spécifique au monde mathématique / informatique. En effet, une définition possible d'un combo utilise la notion de ... combo. De même, une définition de trick_style_mods utilise la notion-même de trick_style_mods. Ce principe de définition, appelé "définition récursive", est délicat à utiliser. En effet, supposons qu'il n'existe qu'une définition possible d'un combo :
Il nous manque en fait ce que l'on appelle, lorsqu'on utilise la récursivité, un "cas terminal", qui permet de produire une "fin" à la définition. Dans le cadre de notre grammaire, ce cas terminal se définit comme suit :
Le principe de récursivité est un monde à part entière. Des langages informatiques sont basés sur ce principe, et en mathématiques, de nombreuses preuves de théorèmes fondamentaux ont vu le jour grâce à la récursivité. Dans le cadre des définitions de grammaires, c'est un élément incontournable pour définir des suites arbitrairement longues d'éléments.
III.4 Ambigüité des grammaires
Une difficulté lors de la création de grammaires est d'éviter les ambigüités. Malgré toute notre minutie, il arrive parfois que notre grammaire puisse interpréter une phrase de deux manières différentes. Prenons l'exemple de la grammaire suivante ( lexique et règles syntaxiques y sont introduites d'un seul coup)
III.1 Définition des règles de syntaxe.
>>> Comment décrypter ces règles syntaxiques ?Exemple 8 : Règles syntaxiques pour le lexique L2.1
combo :
trick |
trick LINK_WORD combo |
combo LINK_WORD combo
-----------------------------
trick :
trick_style_mods trick_direction_mods TRICK_NAME trick_spin_mods
-----------------------------
trick_style_mods :
STYLE_MODIFIER trick_style_mods | rien
-----------------------------
trick_direction_mod :
DIRECTION_MODIFIER | rien
-----------------------------
trick_spin_mod :
SPIN_MODIFIER | rien
-----------------------------
rien :
-----------------------------
Oui, là ça se complique. Plusieurs choses sont à noter :
- On ne définit plus des symboles terminaux, en revanche on les utilise.
- Les nouveaux symboles définis, et écrits ici en minuscule, sont des "symboles non-terminaux", tout simplement parce qu'ils sont eux-mêmes décomposables en zéro, un, ou plusieurs symboles terminaux.
- Et mieux, un symbole non-terminal peut être décomposé en une association de symboles terminaux mais aussi non-terminaux !
On tente ici une description pas à pas de notre grammaire :
un combo est représenté :
* soit par un trick, sur lequel on enchaine, grâce à un symbole de liaison, par un autre combo.
* soit par un combo sur lequel on enchaine, grâce à un symbole de liaison, par un autre combo.
* soit par un simple trick unique. Un combo hyper court, d'un seul trick.
* on refuse ici le concept de "combo vide" qui serait en fait ne rien faire. Si on l'avait accepté, un combo pourrait commencer par zéro trick puis un symbole de liaison, ce qui est un peu moche !
un trick est représenté :
* par un symbole contenant les modificateurs de style (trick_style_mods)
* suivis du symbole modificateur de direction (trick_direction_mods)
* suivis d'un nom de trick (TRICK_NAME)
* suivi de modificateurs de spin (trick_spin_mod)
un trick_style_mods est représenté :
* par un STYLE_MODIFIER suivi d'un autre trick_style_mods
* ou bien par rien du tout.
---> On peut donc discerner le principe : il peut y avoir un STYLE_MODIFIER suivi de rien du tout, ou bien plusieurs STYLE_MODIFIER d'affilée ! Ce principe de définition s'appelle la "récursivité", on y renviendra à la fin de cette partie pour ceux que ça intéresse.
Je vous laisse réfléchir 2 secondes pour comprendre la définition de trick_spin_mod et trick_direction_mod ! Elles différent de celle de trick_style_mods par le fait que cette fois-ci, on n'aura qu'un seul symbole terminal, ou bien rien du tout...
III.2 Analyse "automatique" d'un breakdown.
>>> Et l'analyse elle donne quoi du coup ?
Et bien testons sur quelques exemples, une analyse "automatique" de quelques breakdowns :
Et oui, la machine est bête et méchante, et elle respecte la grammaire mot pour mot... Si elle est bien programmée, peut-être vous suggèrera-t-elle de déplacer vos modifiers dans la définition du deuxième trick... En attendant, elle vous avertira d'une erreur et ne pourra valider le combo !Exemple 9 : test des règles syntaxiques définies précédemment.
Breakdown 1 : sonic > reverse fingerless thumbaround
* Alors c'est parti. Je sais que je dois lire un combo, donc je commence à la règle qui définit un combo...
* Je lis le premier lexême. "sonic". Ok, ça c'est un TRICK_NAME ! Hum, selon mes rêgles de syntaxe, je me trouve donc forcément dans la lecture d'un trick. Vérifions cela !
* Quel est le trick_style_mods dans ma lecture du trick ? Ah ben y a rien avant mon TRICK_NAME... Pas grave, puisque trick_style_mods peut contenir le symbole rien, qui ne contient pas de lexême ! Tout va bien pour l'instant.
* Maintenant le trick_direction_mod ... Ben pareil, la seule possibilité c'est que je lise un rien, et tout va bien !
* Bon, passons au trick_spin_mod ... Après mon TRICK_NAME, je lis ">", qui ne peut être qu'un LINK_WORD d'après mon lexique ! Bon j'en déduis que mon trick_spin_mod était également un rien ...
* Le trick est validé ! Très bien... D'après ma syntaxe cependant, si un combo commence par un trick, il est suivi d'un LINK_WORD ... ah béh oui il est bien là ! Je valide !
* Toujours d'après la syntaxe, je dois donc maintenant m'attendre à trouver un nouveau combo ... Ok, on repart à zéro alors ! Je lis un combo...
* ... Et je lis "reverse". D'après mon lexique, c'est un DIRECTION_MODIFIER, que je trouve que dans la définition d'un trick... Ok, donc je lis un trick et j'ai déjà mon trick_direction_mod ! Et ensuite ?
* Ben avant le trick_direction_mod, y a-t-il un trick_style_mod ? Oui, mais il ne peut valoir que rien. Ben ça me va. Et ensuite ? Je vais devoir lire un TRICK_NAME nécessairement...
* Et ben non, je lis le mot "fingerless", mais d'après mon lexique, ça ne peut pas être un TRICK_NAME ! Flûte alors ... Ben je lisais un trick et j'ai pas de TRICK_NAME ... Y a erreur !
En revanche, si vous lui donnez sonic > fingerless reverse thumbaround 1.5, comment finit-elle le job ? Reprenons juste avant l'erreur ...
Et voilà, comment on fait les bébés ! Tu vois, c'est pas si compliqué . Suffisait de demander !Exemple 9 (suite):
Breakdown 2 : sonic > fingerless reverse thumbaround 1.5
* Alors, j'en étais où... ah oui, je lisais un trick, j'ai lu "fingerless" et "reverse" dans le bon ordre, les modifiers sont là, tout va bien...Qu'en est-il du TRICK_NAME qui doit suivre ?
* Je l'ai trouvé, c'est "thumbaround", qui est bien dans le lexique.
* Ok et ensuite, le trick_spin_mod ... Après le TRICK_NAME je lis "1.5" ... Ca me va très bien comme trick_spin_mod, puisqu'un trick_spin_mod peut être défini par un SPIN_MODIFIER ! Du coup c'est cool, je peux valider la lecture du trick !
* Donc je continue ! j'ai fini la lecture de mon trick, je reviens donc au niveau de la lecture du combo qui commence par le trick "fingerless reverse thumbaround" ...
* Mais il y a rien après ? Et bien, ce n'est pas un problème, puisqu'un combo peut très bien être un simple trick ! Je valide donc ce combo !
* Maintenant je reviens à la lecture générale de mon combo.
* J'ai lu un trick, suivi d'un LINK_WORD, suivi d'un combo. Et bien ma foi c'est parfait, l'une des définitions d'un combo c'est précisément ça !
* Très bien, je valide, le breakdown est correct !
III.3 Récursivité
Certains l'auront remarqué, les définitions lors des règles syntaxiques utilisent un procédé assez spécifique au monde mathématique / informatique. En effet, une définition possible d'un combo utilise la notion de ... combo. De même, une définition de trick_style_mods utilise la notion-même de trick_style_mods. Ce principe de définition, appelé "définition récursive", est délicat à utiliser. En effet, supposons qu'il n'existe qu'une définition possible d'un combo :
Nous sommes en face d'un problème très fréquent en programmation ou en mathématiques. Bien sûr si que l'on lit ne commence pas par un trick, il n'y a pas de problème, mais si par malheur on lit un trick, puis ">", alors comment savoir si la suite est bien un combo ? Et bien on va considérer la partie qui reste à lire comme un combo. Elle doit donc commencer par un trick suivi d'un ">" . Si ce n'est pas le cas, bien sûr, on va produire une erreur. Mais admettons qu'on ne rencontre que des tricks suivis de ">". Le breakdown que l'on a rentré n'est pas infini, il y a donc une fin. Une fois arrivé à la fin du combo, on ne lit plus de trick ou de ">", il va donc nécessairement y avoir une erreur, puisqu'on ne respecte plus la définition du combo ! Cette définition est donc trop limitée...------------------
combo :
trick ">" combo
------------------
trick :
...(peu importe)
------------------
Il nous manque en fait ce que l'on appelle, lorsqu'on utilise la récursivité, un "cas terminal", qui permet de produire une "fin" à la définition. Dans le cadre de notre grammaire, ce cas terminal se définit comme suit :
Cette fois-ci, on sait que si l'on a une suite de trick ">" suivi de rien du tout, ce n'est pas bon, mais que si cette suite est suivi d'un trick seul, alors nous avons bien affaire à un combo. De plus, il permet d'accepter les combos ne comportant qu'un trick, ce que les règles précédentes ne permettaient pas.------------------
combo :
trick ">" combo |
trick
------------------
trick :
...(peu importe)
------------------
Le principe de récursivité est un monde à part entière. Des langages informatiques sont basés sur ce principe, et en mathématiques, de nombreuses preuves de théorèmes fondamentaux ont vu le jour grâce à la récursivité. Dans le cadre des définitions de grammaires, c'est un élément incontournable pour définir des suites arbitrairement longues d'éléments.
III.4 Ambigüité des grammaires
Une difficulté lors de la création de grammaires est d'éviter les ambigüités. Malgré toute notre minutie, il arrive parfois que notre grammaire puisse interpréter une phrase de deux manières différentes. Prenons l'exemple de la grammaire suivante ( lexique et règles syntaxiques y sont introduites d'un seul coup)
Testons cette grammaire sur quelques exemples.Exemple 10 : Une grammaire G ambigüe
--------------------
NOM : "alex" | "mathieu" | "pierre" | "alexandre"
--------------------
COORDINATION : "et" | "ou"
--------------------
VERBE : "aime" | "mange" | "trucide" | "chatouille"
--------------------
phrase :
action COORDINATION phrase |
action
--------------------
action :
sujet VERBE complément
--------------------
sujet :
NOM |
NOM COORDINATION sujet
--------------------
complément :
NOM |
NOM COORDINATION complément
--------------------
Jusque-là, c'est comme sur des chapeaux de roue ! Cependant tout devient bancal si on utilise la règle qui définit une phrase comme une suite action COORDINATION phrase :Exemple 11 : Test de la grammaire G ambigüe
"alex aime mathieu" : une phrase, qui est une action, qui contient un sujet sous forme de NOM, un VERBE, un complément sous forme de NOM. Pas de problème.
"pierre et mathieu trucide alexandre" : outre le VERBE mal conjugué, ça marche. La seule différence avec l'exemple précédent est que le sujet est sous forme de NOM COORDINATION sujet, avec ce second sujet comme un NOM. ça reste correct.
Cet exemple prouve l'ambigüité dont certaines grammaires font preuve. Fort heureusement, les outils informatiques qui nous permettent d'écrire facilement des grammaires permettent de détecter les problèmes à l'origine de cette ambigüité, au moins en pointant du doigt les règles où l'ambigüité peut surgir. Cependant, mieux vaut rester prudent et bien construire sa grammaire, car si l'on veut produire, en plus de l'analyse grammaticale, une analyse sémantique, et bien on se retrouve un peu ***illon, comme dans l'exemple précédent.Exemple 11 :[/u] Test de la grammaire G la montrant ambigüe
"pierre chatouille alexandre et alex et mathieu mange pierre" . Ok alors là je lis une phrase sous forme de action COORDINATION phrase ... mais quelle est la COORDINATION ? Est-ce le premier ou le deuxième "et" ? Dans les deux cas les définitions sont respectées... Ce n'est pas gênant pour l'acceptation grammaticale du mot, mais quel sens devra-t-on ensuite donner à la phrase ?
(pierre chatouille alexandre et alex) et mathieu mange pierre
ou
pierre chatouille alexandre et (alex et mathieu mange pierre)
?
La troisième étape est donc la production de sens. Je ne vous fournirai pas un descriptif des méthodes d'analyse sémantique, tout simplement parce qu'il n'existe pas à ma connaissance de théorie qui puisse décrire les méthodes d'analyse sémantique pour n'importe quelle grammaire, et dans n'importe quel contexte...
IV.1 Application au domaine du penspinning
Ici, tout dépend de ce que VOUS voulez faire ! Cela peut prendre la forme de programmes informatiques complexes, ou bien d'un simple affichage de "votre breakdown est grammaticalement correct." dans une page HTML. Oui ça aussi c'est une action sémantique, aussi idiot que cela puisse paraitre !
Dans le cadre d'une grammaire pour les breakdowns, certains points sont à ne pas négliger. Un breakdown a beau être grammaticalement correct, cela ne veut pas dire qu'il ait du sens. Qu'en est-il du combo "backaround > sonic" selon ma grammaire au-dessus ? Si l'on traduit cela comme "backaround 12-12 > sonic 23-12", et bien le combo est tout simplement impossible, il manque quelque chose, ou bien il y a quelque chose en trop ! En tout cas les fingerslots ne se correspondent pas.
Un but de l'analyse sémantique pour notre langage de descrption des breakdowns pourrait par exemple être de vérifier si les fingerslots se correspondent. Quelques autres idées qui peuvent faire partie de l'analyse sémantique d'un combo :
* vérifier les fingerslots
* vérifier un sens de rotation contraint (tout CCW, ou tout CW, etc)
* compter le nombre de changements de sens de rotation
* calculer un quota de tricks "reverse" / tricks "normal"
* compter le nombre de tours total
* stocker des informations quelque part et effectuer des statistiques sur une large base de combos, comme le proposait Zombo
* produire une vidéo pas-à-pas de la réalisation du combo ?
* générer un affichage de liens vers des tutoriaux pour les tricks utilisés ?
* tout simplement définir notre combo sous un nom, par exemple "superCombo_1", et l'utiliser sous ce nom dans un breakdown ultérieur pour raccourcir la longueur de ce second breakdown ? Mais là on touche vraiment à des principes de programmation
* rechercher l'existence du combo ou du trick dans une base de données pour voir s'il possède un nom, qui l'a introduit dans la base, qui en revendique la propriété, etc...
Les possibilités lors de l'analyse sémantique ne dépendent que de notre imagination, et du savoir-faire mis à notre disposition en terme de capacités de programmation. Imaginez un programme validateur de combos qui génèrerait automatiquement une vidéo virtuelle en 3D de votre combo, vous permettant de choisir l'angle de caméra, la vitesse d'exécution... Et donc d'anticiper les passages moches pour les corriger... On rêvasse un peu, mais des choses de ce genre ne sont pas si impossibles une fois la vérification de la validité d'un breakdown effectuée...
Vos idées comptent, et une fois l'étape de l'analyse grammaticale franchie, tout pen spinner est capable de proposer et de participer à l'élaboration de concepts. C'est pour ça que définir un langage formel, unifié et automatisable des breakdowns est, peut-être pas un besoin, mais au moins quelque chose d'utile, susceptible de faire évoluer la discipline vers une autre dimension, ou l'exploitation de l'informatique repousse les frontières du monde du penspinning.
IV.2 Conclusion sur ce petit tuto
Bon ben, pas grand-chose à dire ici, j'espère que vous avez trouvé ce tutorial intéressant...
Je suis à votre disposition pour répondre à vos questions, par MP ou publiquement dans ce topic. N'hésitez pas à me signaler si certains passages sont particulièrement obscurs, voire incorrects (certains ici sont certainement meilleurs que moi en informatique), ou si vous désirez plus d'informations sur un point précis.
A bientôt pour de nouvelles aventures, bande de geeks !
IV.1 Application au domaine du penspinning
Ici, tout dépend de ce que VOUS voulez faire ! Cela peut prendre la forme de programmes informatiques complexes, ou bien d'un simple affichage de "votre breakdown est grammaticalement correct." dans une page HTML. Oui ça aussi c'est une action sémantique, aussi idiot que cela puisse paraitre !
Dans le cadre d'une grammaire pour les breakdowns, certains points sont à ne pas négliger. Un breakdown a beau être grammaticalement correct, cela ne veut pas dire qu'il ait du sens. Qu'en est-il du combo "backaround > sonic" selon ma grammaire au-dessus ? Si l'on traduit cela comme "backaround 12-12 > sonic 23-12", et bien le combo est tout simplement impossible, il manque quelque chose, ou bien il y a quelque chose en trop ! En tout cas les fingerslots ne se correspondent pas.
Un but de l'analyse sémantique pour notre langage de descrption des breakdowns pourrait par exemple être de vérifier si les fingerslots se correspondent. Quelques autres idées qui peuvent faire partie de l'analyse sémantique d'un combo :
* vérifier les fingerslots
* vérifier un sens de rotation contraint (tout CCW, ou tout CW, etc)
* compter le nombre de changements de sens de rotation
* calculer un quota de tricks "reverse" / tricks "normal"
* compter le nombre de tours total
* stocker des informations quelque part et effectuer des statistiques sur une large base de combos, comme le proposait Zombo
* produire une vidéo pas-à-pas de la réalisation du combo ?
* générer un affichage de liens vers des tutoriaux pour les tricks utilisés ?
* tout simplement définir notre combo sous un nom, par exemple "superCombo_1", et l'utiliser sous ce nom dans un breakdown ultérieur pour raccourcir la longueur de ce second breakdown ? Mais là on touche vraiment à des principes de programmation
* rechercher l'existence du combo ou du trick dans une base de données pour voir s'il possède un nom, qui l'a introduit dans la base, qui en revendique la propriété, etc...
Les possibilités lors de l'analyse sémantique ne dépendent que de notre imagination, et du savoir-faire mis à notre disposition en terme de capacités de programmation. Imaginez un programme validateur de combos qui génèrerait automatiquement une vidéo virtuelle en 3D de votre combo, vous permettant de choisir l'angle de caméra, la vitesse d'exécution... Et donc d'anticiper les passages moches pour les corriger... On rêvasse un peu, mais des choses de ce genre ne sont pas si impossibles une fois la vérification de la validité d'un breakdown effectuée...
Vos idées comptent, et une fois l'étape de l'analyse grammaticale franchie, tout pen spinner est capable de proposer et de participer à l'élaboration de concepts. C'est pour ça que définir un langage formel, unifié et automatisable des breakdowns est, peut-être pas un besoin, mais au moins quelque chose d'utile, susceptible de faire évoluer la discipline vers une autre dimension, ou l'exploitation de l'informatique repousse les frontières du monde du penspinning.
IV.2 Conclusion sur ce petit tuto
Bon ben, pas grand-chose à dire ici, j'espère que vous avez trouvé ce tutorial intéressant...
Je suis à votre disposition pour répondre à vos questions, par MP ou publiquement dans ce topic. N'hésitez pas à me signaler si certains passages sont particulièrement obscurs, voire incorrects (certains ici sont certainement meilleurs que moi en informatique), ou si vous désirez plus d'informations sur un point précis.
A bientôt pour de nouvelles aventures, bande de geeks !
