flex/bison outils adaptés pour ce que je veux faire ?

Bonjour.

Désolé de ne pas avoir mis de titre plus clair, mais je ne voyais pas comment résumer.

Je voudrais ajouter des fonctionnalités à un langage script déjà existant, notamment y rajouter des paradigmes inexistants tel que la compilation conditionnelle, et certains aspects de la POO ainsi que le type "struct" (qui sera convertit en collection d'arrays), des define, etc.

Le but est de rajouter du sucre syntaxique à un langage déjà existant, et de vérifier les syntaxes lexicale et syntaxique, voir aussi sémantique, puis de générer le code script correspondant.

Premier point qui fâche impossible de trouver la documentation officielle en français, je ne suis pas anglophobe mais pour les choses relativement complexe je préfère quand même la langue de Molière.
M'enfin tout cela pour dire que si vous avec un lien de la doc en français je suis preneur, sinon je ferais avec ^^

Je me demandais donc si ces outils étaient adaptés à ce que je veux faire ou s'il vaut mieux que je le réalise de A à Z sans ces outils.
La performance n'est pas la priorité même si bien entendu il ne vaudrait mieux pas que cela soit l'usine à gaz. (Au pire les plus gros codes ne dépasseront pas les 30 000 lignes de code à parser)

La simplicité et clarté du code prime, même si bien entendu dans l'éventualité de l'utilisation de ces outils je devrais bien évidemment passer par la case apprentissage.

Bonjour,

Dans les tutoriels, vous pouvez chercher sur cette page, section Théorie des langages.

Flex/Bison sont des outils pour l'analyse lexicale et syntaxique, donc il semble appropriés pour ce que vous décrivez.

Maintenant, je ne connais pas plus les outils que cela, mais je pense que c'est possible. Il faudra peut être un programme en sortie de Flex pour faire les dernières choses dont vous avez besoin (genre, le compilateur en lui même ; après l'analyse du fichier source), mais vous pouvez tenter de faire écrire votre script "compilé" par Flex (Compilé, dans le sens, traduit en vrai ligne de script valide).

Bonjour

Citation:

---

Envoyé par AnozerOne

Je voudrais ajouter des fonctionnalités à un langage script déjà existant, notamment y rajouter des paradigmes inexistants tel que la compilation conditionnelle, et certains aspects de la POO ainsi que le type "struct" (qui sera convertit en collection d'arrays), des define, etc.

Le but est de rajouter du sucre syntaxique à un langage déjà existant, et de vérifier les syntaxes lexicale et syntaxique, voir aussi sémantique, puis de générer le code script correspondant.

---

Effectivement, Lex & Yacc servent à ça. Par contre, d'une part, ce n'est effectivement pas évident et, d'autre part, c'est le « langage déjà existant » qui me laisse perplexe. De quel langage s'agit-il ?

En outre, si c'est pour lui permettre d'être interprété par le même programme, alors tu as peut-être plus vite fait de modifier le parser existant.

Citation:

---

Je me demandais donc si ces outils étaient adaptés à ce que je veux faire ou s'il vaut mieux que je le réalise de A à Z sans ces outils. La performance n'est pas la priorité même si bien entendu il ne vaudrait mieux pas que cela soit l'usine à gaz. (Au pire les plus gros codes ne dépasseront pas les 30 000 lignes de code à parser)

---

Disons qu'il y a des « plus » comme des « moins » : Lex & Yacc (ou ses clones) sont des outils assez vieux et je n'en connais pas qui soient à la fois plus simples et mieux écrits. Le code généré en C n'est pas non plus un modèle de propreté, et il faudra beaucoup tâtonner au départ pour être à l'aise avec la manière de tout déclarer (notamment les types des tokens) et pour manipuler ensuite les données extraites, spécialement les chaînes de caractères, qui restent toujours un exercice un peu pénible en C.

Sur le plan formel, maintenant, il n'y a pas photo : tu as tout à gagner à passer par ce genre d'outils si tu veux complexifier la grammaire de ton langage de script : tout « conflit décalage réduction » que tu rencontreras dans ta définition (et tu en rencontreras, fais-moi confiance) se serait inévitablement traduit par un plantage ou un bug dans un parser dédié écrit uniquement pour ton langage.

Par contre, j'espère quand même que tu disposes déjà de la grammaire de ton langage existant. Sinon, la réécrire avant de l'étendre risque d'être assez ardu. Par contre, ce sera très instructif.

Le langage existant est le jass (langage script fortement typé et verbeux, il est intréprété, ou transformé en byte code mais cela dépasse mes connaissances, et comme expliqué ci dessous je n'ai pas à m'en soucier).
C'est le langage utilisé par l'éditeur de carte de warcraft 3.
Pour ceux qui connaissent je veux faire un peu comme le cJass (avec des modifications et aussi rajouts de plus de POO et autres paradigmes) mais je ne compte pas faire comme lui c'est à dire générer du code vJass, en fait je ne compte pas supporter le vJass, ni le cJass, ni même le jass.
Tout simplement parce que ce mélange de jass/vJass/cJass est ignoble et qu'il est bien plus complexe de gérer plusieurs grammaires différentes et redondantes.

Comme le script de la map est un simple fichier texte qui doit se nommer war3map.j, il n'y a pas à probablement parler de parseur à réaliser, dans le sens ou ce qu'une map a besoin est un simple fichier texte en langage jass.
Mais je dois quand même transformer le tJass (nom de mon pseudo langage) en jass, le principe étant le même.

Le jeu commence vraiment à vieillir et je le le fais avant tout pour moi même, pour le fun et car le sujet m'intéresse beaucoup.
Je ne compte pas vraiment avoir des utilisateurs potentiels (faudrait déjà que j'écrive une documentation valide :p), ni même l'utiliser sérieusement, autrement que pour valider son fonctionnement.

Je me doute que cela représente beaucoup de travail, mais quand on aime on ne compte pas ^^

Sinon pour la grammaire, je vais en effet y penser sérieusement avant de m'y lancer tête baissée (je parle de ma surcouche au langage existant).
EDIT : Je viens de comprendre en relisant, oui j'ai la grammaire du langage existant qui est assez basique et limitée.

Mais un doute me taraude quand même, quid des types dynamiques définis par l'utilisateur (comme les struct) ?
Ces outils sont ils capables de les inclure dans leur analyses (lexicale pour Flex et syntaxique pour Bison), ou peut être dois je le faire dans l'analyse sémantique ?
Parce que les définitions de ces outils me semblent statiques.

Tout d'abord merci de vos réponses (oubli de ma part)

Comme mon edit semble être passé inaperçu, je me permets de me citer :

Citation:

---

Mais un doute me taraude quand même, quid des types dynamiques définis par l'utilisateur (comme les struct) ?
Ces outils sont ils capables de les inclure dans leur analyses (lexicale pour Flex et syntaxique pour Bison), ou peut être dois je le faire dans l'analyse sémantique ?
Parce que les définitions de ces outils (grammaire) me semblent statiques.

---

Si je ne suis pas assez clair n'hésitez pas à m'en faire part, je tacherais d'y remédier.

Hello,

Non, ce n'est pas pas passé inaperçu. J'étais bien tenté de te répondre que non, les outils en question ne peuvent pas insérer dynamiquement des types définis dans leur grammaire mais, à bien y réfléchir, je ne les connais pas suffisamment en détail pour pouvoir l'affirmer.

Cela dit, tu as toujours le droit d'utiliser ton propre lexer et de le combiner à Yacc, tu peux aussi amender le code produit par Lex si nécessaire.

Quoi qu'il en soit je suppose que c'est une bonne base pour commencer, ne serait ce que pour définir clairement et simplement la grammaire, le sens de lecture des opérandes (droite ou gauche) ainsi que leur priorité.
Pour me faciliter la vie je vais surement aussi définir des règles strictes pour la grammaire des différents type, un peu comme le fait le langage ruby.

Je vais me plonger dans la documentation mais d'après la FAQ et la description de ces outils, tout laisse à penser que les types dynamiques doivent être gérés de A à Z par l'utilisateur, indépendamment de ces outils.

Puis quand j'aurais bien assimiler les techniques à mettre en oeuvre je pourrais toujours me passer de ces outils et construire mon propre analyseur plus adapté et optimisé "from crash".

En fait, comme je le disais, le rôle principal du lexer est de reconnaître un token individuel puis de renvoyer son identifiant à Yacc qui, lui, le gérera grammaticalement. Dès lors, rien ne t'empêche de faire un lexer dynamique donc tu feras grossir le glossaire au fur et à mesure, et continuer à t'appuyer sur Yacc pour faire une analyse grammaticale statique.

Tu dois même, je pense, pouvoir faire un hook sur Lex pour le faire. Je ne sais pas comment a priori mais il serait très étonnant que ce soit impossible…