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]

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

[levit]

Merci pour le récapitulatif Emmanuel.

Pour en revenir à Coco/R, son avantage sur Lex/Yacc est donc sa capacité à travailler avec C++. Par contre il me semble moins répandu que Lex/Yacc.
J'ai vu que Flex/Bison propose une version C++ que j'ai commencé à tester brièvement. Pensez vous que ce soit une solution viable ?

J'en profite pour demander à quel point Lex/Yacc (ou leurs pendant GNU) est présent "d'origine" sur les différents unix ?

[NewbiZ]

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"

Il faudrait plus d'exemples de ce que tu comptes faire avec ce langage.
Il n'y a aucun sens à vouloir utiliser des outils aussi complexes que Lex et Yacc pour un langage qui à priori a l'air aussi simple que celui présenté.