Interpr�teur de scripts

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.

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 ;)

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...

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.

Citation:

---

Envoy� par 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...

---

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.

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.

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.

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.

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

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

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:

Citation:

---

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).

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" ;)

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:

---

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:

---

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.

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.

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

Citation:

---

Envoy� par 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 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.

Citation:

---

Envoy� par levit

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.

Citation:

---

Envoy� par 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.

---

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).

- 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:

---

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:

---

1 2 3 4

NEW IMAGE IMAGE LOAD "monImage.jpg" IMAGE SEUIL 128 IMAGE SAVE "monImageBis.jpg"

---

Mon main ressemblerait alors � ceci ;

Code:

---

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().

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++.

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 :D

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.