Discussion :

[levit]

Bonjour,


Avant tout je tiens à préciser que je vous sollicite afin d'avoir quelques pistes, un aiguillage plutôt qu'une solution clé en main.

Je dispose d'une application développée en C++ que je contrôle par son interface graphique.

Dans un souci d'automatisation de tâches, je veux créer un langage script très simple pour contrôler mon application non plus par son interface graphique mais par des commandes que j'écrirai dans un fichier texte.
Je souhaite donc ajouter à mon application un interpréteur de scripts qui lise le fichier en question et qui effectue les actions demandées par les mots clés qui s'y trouvent.

En ce moment je cherche des conseils pour adopter le meilleur design possible.

D'avance merci pour votre aide.

[koala01]

Salut,

Peut être devrais tu, tout simplement, te tourner vers les bibliothèques de "scripting" existantes, telles que lua...

Autrement, il te reste toujours, pourquoi pas, la possibilité de te tourner, presque de manière tout aussi simple, vers un script shell, ou batch, selon le système d'exploitation que tu utilise

[levit]

Bonsoir et merci pour ta réponse,

Je ne connaissais pas lua. Il s'agit d'un langage déjà existant avec son interpréteur.

Ce n'est pas une solution qui me convient puisque je souhaite moi même définir mon propre langage (avec mes propres mot clés) et intégrer "l'interpréteur de scripts", que je dois donc réaliser, à l'application existante.

Donc, ce qui pourrait m'intéresser ce serait d'avantage de trouver un diagramme UML d'un interpréteur de scripts existant pour voir comment il est "designé", comment il lit les différentes chaines de caractères, et tout et tout...

[JolyLoic]

Des solutions à base de lua ou python utilisent certes un langage déjà existant, mais quand tu l'intègres dans ton programme, il peuvent accéder directement à des objets que tu as défini toi, en fonction des particularité de ton code.

Tu bénéficies donc de la puissance d'un vrai langage, de plein de bibliothèques externes, et d'un temps de développement réduit.

Si maintenant, tu veux vraiment définir ton propre langage, pour une raison que je ne connais pas (curiosité, par exemple) dans ce cas, tu vas devoir te tourner vers la notion de lexeur/parseur pour analyser le code écrit. Tu devrais trouver pas mal de choses en cherchant lex/yacc, flex/bison, antlr, et boost::spirit.

[Emmanuel Deloget]

Bonsoir et merci pour ta réponse,

Je ne connaissais pas lua. Il s'agit d'un langage déjà existant avec son interpréteur.

Ce n'est pas une solution qui me convient puisque je souhaite moi même définir mon propre langage (avec mes propres mot clés) et intégrer "l'interpréteur de scripts", que je dois donc réaliser, à l'application existante.

Donc, ce qui pourrait m'intéresser ce serait d'avantage de trouver un diagramme UML d'un interpréteur de scripts existant pour voir comment il est "designé", comment il lit les différentes chaines de caractères, et tout et tout...

Sinon, pour répondre à ces questions spécifiques, des recherches google sur les mots clef "analyse lexicale", "analyse syntaxique", "générateur de parser" et les équivalent en anglais de ces termes te fourniront un ensemble de réponses que tu pourras exploiter.

Ceci-dit, je te conseilles d'utiliser un langage existant, tu auras au moins l'assurance que ça marche. lua est très simple d'utilisation, et te permet de définir dans ton programme un environnement d'exécution qui est partagé avec les scripts.

[levit]

Disons que le langage que je souhaite créer se veut d'une simplicité extrême, avec un nombre réduit de mots.

Les différentes pistes que vous m'avez données me semblent très intéressantes, je creuse dans ce sens pour faire mon choix.

[Jean-Marc.Bourguet]

TCL est, à mon avis, aussi à considérer. Par certains aspects il est moins agréable que d'autres langages de script, mais il n'a pas été conçu comme langage de programmation mais comme langage de commande (TCL -> tool command language). Dans un sens, c'est un vrai langage de script tandis que Python etc sont des langages de programmation.

Vur l'aspect historique de l'utilisation du mot, voir aussi http://www.developpez.net/forums/sho...95&postcount=3.

[levit]

Je me suis désormais renseigné sur les propositions que vous m'avez faites.

lex/yacc me semble être "intrinsèquement" la manière la plus intelligente d'aborder mon projet. Seulement, j'ai décidé de "réinventer l'eau tiède" et de créer mes propres outils à partir des bibliothèques standard.

J'ai lu bon nombre de cours sur la théorie de la compilation puisque ce problème s'apparente finalement au mien. J'ai donc des notions d'analyse syntaxique, lexicale, d'arbres syntaxiques etc.

Cependant je ne sais pas comment m'y prendre pour implémenter l'affaire.
J'imagine que le pattern interpreter (http://www.dofactory.com/Patterns/Pa...terpreter.aspx) doit pouvoir être mis à profit.

Bref, le sujet m'a l'air quand même très documenté mais je n'arrive pas à trouver des informations concrètes sur le design à adopter pour mon interpréteur de scripts.

[flyweight]

Vous pouvez utilisez AngelScript, son intégration ne nécessite pas beaucoup d'effort, sinon Flex/Bison est très efficace ... mais si tu veut vraiment réinventer la roue jette un coup d'œil sur http://www.oberon2005.ru/book/ccnw2005e.pdf

[levit]

Merci pour la réponse, mais comme je le disais juste au dessus, je ne tiens pas à utiliser quelque solution existante que ce soit.

[Jean-Marc.Bourguet]

Si ton objectif est bien l'application et non apprendre a faire un interpreteur ou explorer des concepts de langages, je te rappelle la loi:

Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp.

On se dit qu'on n'a pas besoin de quelque chose d'aussi complexe et avant qu'on s'en rende compte on passe plus de temps a gerer le langage qui n'est plus si simple que l'application.

J'ai pas le temps d'ecrire le bouquin qu'il faudrait pour repondre au fond de ta question. http://compilers.iecc.com/crenshaw/ pourait etre utile mais je ne connais rien d'equivalent sur les interpreteurs (encore qu'il doit y avoir pas mal de ressources si l'interpreteur que tu cherches a faire est un interpreteur lisp, c'est un exercice classique).

[koala01]

Le pattern "interpréteur" semble effectivement particulièrement adapté à ton souhait, mais...

• Il ne faut malgré tout pas verser dans la "paternite" car, au final, tu risque d'avoir besoin de plus que ce seul pattern
• Comme l'a indiqué (en anglais) jean-marc, il faut aussi te méfier du fait que ce qui peut te sembler limité, simple et restreint au départ peut très rapidement devenir ample, complexe et indigeste avant même que tu ne commence à t'en rendre compte
• je ne nie absolument pas l'intérêt didactique du fait de créer ton propre interpréteur pour ton propre langage, mais je te conseille quand même de réfléchir au fait que le temps que tu passera à mettre ton langage au point, puis à coder l'interpréteur qui permettra de l'utiliser *pourrait* sans doute être utilisé autrement afin de rendre ton travail plus tôt...
• L'expérience montre qu'il est beaucoup plus facile et surtout plus rapide de s'adapter à ce qui existe (qui fonctionne généralement bien, et qui a sans doute été mis au point en un temps assez long par une équipe) que de repartir "de rien", seul, et de devoir tout réinventer...

Ce serait sans doute un comble si nous venions à t'interdire quoi que ce soit, ne serait ce que parce que "c'est ton choix" et que tu es donc seul juge de l'appliquer ou non

Cependant, surtout quand on voit le temps qu'il t'a fallu pour prendre cette décision, tu ne pourras pas nous empêcher de penser que tu fais sans doute fausse route... parce que "c'est notre choix"

[levit]

Ce dont j'ai peur avec Lex/Yacc c'est de ne pas réussir l'intégration dans mon application. Du moins, je n'ai pas trouvé d'exemple à ce jour qui me convainque du contraire.

Je prends l'exemple classique d'une application qui manipule des images via une classe TImage.

En l'état actuel des choses, si je souhaite réaliser un seuillage sur une image, je peux modifier le contenu de mon main comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
int main (void)
{
   TImage I;
   I.lire("monImage.jpg");
   I.seuillage(128);
   I.sauvegarde("monImageBis.jpg");
   return(0);
};

Dans ce cas, au lieu de modifier ainsi mon main, mon idée serait de pouvoir avoir un fichier script dans lequel j'écrirais par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
NEW IMAGE 
IMAGE LOAD "monImage.jpg"
IMAGE SEUIL 128
IMAGE SAVE "monImageBis.jpg"

Est-ce que c'est faisable avec Lex/Yacc ?
Est-ce que c'est très faisable avec Lex/Yacc ?
Est-ce que ça nécessite d'utiliser Lex/Yacc ?

Je manque certainement encore de recul sur tout ça pour me faire une idée bien claire de ma situation.

[loufoque]

Un langage "propre", ça se conçoit comme ceci
- un lexer, qui va prendre un flux de caractères et retourner un flux de tokens, tout en rejetant les tokens mal construits
- un parser, qui va prendre un flux de tokens et générer un arbre de syntaxe abstrait, tout en rejetant les syntaxes invalides
- un analyseur, qui va vérifier la sémantique du programme, en annotant éventuellement l'arbre
- un interpréteur ou un compilateur, qui va évaluer ou transformer l'arbre.

lex/flex permet de générer automatiquement un lexer à partir d'une grammaire EBNF ou similaire, et yacc/bison de même mais pour un parser.
Si ton langage est suffisamment simple (LL(k)), néanmoins, tu peux les écrire à la main par descente récursive, ce qui reste du code assez beau.

[yan]

Tu pourrais aussi regarder du coté de Qt.script qui est basé sur ECMAScript
http://qt.developpez.com/doc/latest/...guage-overview

[levit]

Un langage "propre", ça se conçoit comme ceci
- un lexer, qui va prendre un flux de caractères et retourner un flux de tokens, tout en rejeter les tokens mal construits
- un parser, qui va prendre un flux de tokens et générer un arbre de syntaxe abstrait, tout en rejetant les syntaxes invalides
- un analyseur, qui va vérifier la sémantique du programme, en annotant éventuellement l'arbre
- un interpréteur ou un compilateur, qui va évaluer ou transformer l'arbre.

lex/flex permet de générer automatiquement un lexer à partir d'une grammaire EBNF ou similaire, et yacc/bison de même mais pour un parser.

C'est ce que j'ai compris au fil de mes lectures.
Ce que je vois mal, c'est comment intégrer ces analyseurs dans mon application.

[Emmanuel Deloget]

C'est ce que j'ai compris au fil de mes lectures.
Ce que je vois mal, c'est comment intégrer ces analyseurs dans mon application.

D'ou l'idée de te faire utiliser un système déjà existant, tel que Lua - vraiment très simple, et proche de ce que tu souhaites faire

Il ne faut pas oublier qu'un script s'exécute dans un contexte donné. Une fois l'exécution commencée, seul la fin de l'exécution du script te fait sortir de ce contexte(1). De fait, l'ensemble des opérations est assimilable à une seule fonction, qui exécute les 4 opérations décrites par loufoque en séquence.

Le vrai problème ne vient donc pas de l'intégration de cette fonction dans un programme, mais du lien entre cette fonction et le programme. Si le contexte d'un script ne contient pas le contexte de l'application (ou une partie de celui-ci: fonctions, variables), alors l'interpréteur de script n'a pas beaucoup d'utilité, car l'ensemble des opérations effectuée par le script interprété n'a pas d'effets sur l'application qui l'exécute.

Il convient donc d'injecter certaines variables et certaines fonctions dans le contexte de l'interpréteur de script. Fort heureusement, ce n'est pas compliqué.

Tout langage se base sur l'interprétation de symboles représentés par des identifiants. L'interpréteur peut créer ces symboles lorsqu'il parse le script (note: le parsing peut s'effectuer de deux manières: parse complet du fichier (compilation), ou parse ligne par ligne, voire statement par statement), notamment lors de la définition de variables ou de fonctions. Il est alors obligé de typer en partie ces symboles (ne serait-ce que pour dire que ce sont des symboles) et de stocker ces informations dans une table. L'application qui utilise l'interpréteur peut parfaitement avoir accès à cette table et prédéfinir certains symboles avant de charger et d'exécuter le script. Cela permet au script de faire référence à ces symboles.

Ce dont j'ai peur avec Lex/Yacc c'est de ne pas réussir l'intégration dans mon application. Du moins, je n'ai pas trouvé d'exemple à ce jour qui me convainque du contraire.

Le couple lex/yacc n'est pas forcément le meilleur choix à l'heure actuelle, en particulier si tu souhaites générer un parseur C++. Je te conseilles de te pencher sur des solutions alternatives - il en existe des tonnes (Coco/R, LAPG, ...)

(1) modulo les erreurs remontées par l'interpréteur ou l'interruption de la tâche décidées par des conditions externes (arrêt du programme ou de la thread, etc).

[levit]

- lua
- script shell
- script batch
- TCL
- lex/yacc
- flex/bison
- antlr
- boost::spirit
- AngelScript
- Qt.script
- Coco/R
- LAPG

Comprenez que je me retrouve avec plus d'interrogations que j'en avais au début. J'imagine que l'une de ces solutions correspond mieux à mon souhait que les autres.

Je rappelle brièvement, pour recadrer le sujet, ce que je souhaite faire en reprenant et en complétant l'exemple de la page précédente :

Je prends l'exemple classique d'une application qui manipule des images via une classe TImage.

En l'état actuel des choses, si je souhaite réaliser un seuillage sur une image, je peux modifier le contenu de mon main comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 int main (void)
{
   TImage I;
   I.lire("monImage.jpg");
   I.seuillage(128);
   I.sauvegarde("monImageBis.jpg");
   return(0);
};

Dans ce cas, au lieu de modifier ainsi mon main, mon idée serait de pouvoir avoir un fichier script dans lequel j'écrirais par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
NEW IMAGE 
IMAGE LOAD "monImage.jpg"
IMAGE SEUIL 128
IMAGE SAVE "monImageBis.jpg"

Mon main ressemblerait alors à ceci ;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 int main (void)
{
   lire_interpreter_executer("monFichierScript");
};

L'objet est donc bien la stratégie à adopter pour créer cette fonction lire_interpreter_executer().

[Emmanuel Deloget]

Beaucoup de choses ont été citées. Un petit décryptage:

- lua -> langage de script existant; peut être intégré dans une application. Simple, rapide, puissant et facile à intégrer.
- script shell -> intrepréteur de script externe à ton application
- script batch -> intrepréteur de script externe à ton application
- TCL -> langage de script existant; peut être intégré dans une application
- lex/yacc -> outils permettant de générer des lexeurs et de parseurs; les code sources générés sont écrits dans le langage C.
- flex/bison -> versions GNU de lex (flex) et yacc (bison)
- antlr -> outil permettant de générer des lexeurs et de parseurs; les code sources générés sont écrits dans le langage Java, C# ou C.
- boost::spirit -> bibliothèque C++ "simplifiant" l'écriture de lexeurs et de parseurs
- AngelScript -> langage de script existant; peut être intégré dans une application
- Qt.script -> langage de script existant; peut être intégré dans une application
- Coco/R -> outil permettant de générer des lexeurs et de parseurs; les code sources générés sont écrits dans de multiples langages, y compris C++.
- LAPG -> outil permettant de générer des lexeurs et de parseurs; les code sources générés sont écrits dans de multiples langages, y compris C++.

[zais_ethael]

Haha, un sujet parlant de la théorie des langages, génial.
Bon, on a déjà cité plusieurs documents mais bizarrement aucun qui figure sur developpez. C'est bien dommage vu qu'il sont assez bien faits et ont le mérite d'être en français. On en trouve notamment la et la et il y a aussi un bouquin sur lequel je lorgne depuis un bout de temps ici.

Ensuite, je ne pense pas que ce soit une bonne chose de catapulter un néophyte d'entrée de jeux vers lex/flex yacc/bison. Tout d'abord parce que leur utilisation ne dispense absolument pas de la théorie nécessaire et ensuite parce que je trouve beaucoup plus instructif de commencer par un lexer hardcodé et un parser descendant full-hardcodé lui aussi. Ca permet de comprendre beaucoup mieux le fonctionnement, de mieux assimiler le BNF (ho, pourquoi il est ambigu mon langage?) et surtout c'est plus ludique (à partir du moment où on peut concevoir que la programmation puisse s'avérer être une activité ludique, beaucoup me contrediraient sur ce point).

Ca c'était mon avis sur la façon d'apprendre la théorie des langages. Maintenant, pour ce qui est des motivations, je n'en vois que deux:
- pour s'amuser, parce qu'on trouve ça intéressant
- pour concevoir un langage nouveau, avec de bon concepts et qui sera utilisé par des milliers de personnes, en sachant que l'investissement en temps et en personnes pour obtenir un truc vaguement potable est considérable. Pour te dire, dans mon cours de théorie du langage nous avons du réaliser un compilateur/interpréteur. Il fait à peu près 2200 lignes de codes en excluant la partie génération d'assembleur (pour un programme d'école c'est pas rien), a demandé le travail de quatre personnes chacun se concentrant sur un partie de la théorie. Au final ce langage permet tout au plus de calculer une factorielle et une suite de fibonnaci (des exemples triviaux), et je l'estimerais deux cents fois plus lent que le Java (je suis gentil). Pour autant, c'est loin d'être le plus mauvais de la classe

Alors pour conclure, si ta motivation est la première bonne chance. Si c'est la seconde passe ton chemin, le scripting est un besoin récurrent dans beaucoup de domaines, voila pourquoi il existe une foule de langages prêts à l'emploi pour ça. C'est un parfait exemple de tâche où il est ridicule de réinventer la roue.