Discussion :

[Jean-Marc.Bourguet]

Joli ! Gères-tu la priorité entre les opérateurs ?

Ce parseur la est de la descente recursive: il y a en gros une fonction par non terminal dans la grammaire et on appelle la fonction qui va bien ou ca va bien. C'est le genre de code qui est genere par certains types de generateurs. (Avec ces generateurs, je me retrouve souvent en fait a penser au code final que je veux puis a essayer de l'exprimer dans la syntaxe du generateur).

Mais si tu veux complexifier (ne serais-ce qu'un tout petit peu) ta grammaire, ça devient vite emmerdant à maintenir.

Oui et non. Si la grammaire change tout les jours et est suffisamment sous contrôle pour que ses changements respectent les contraintes du générateur, je suis d'accord. Sinon, le travail d'adaptation aux contraintes du générateur est tout aussi emmerdant -- et avec certains générateurs, beaucoup moins intuitif.

Sinon, j'ai de l'experience en la matiere avec des parseurs ecrits a la main et des parseurs utilisant des generateurs (j'ai meme ecrit des generateurs). A la fois pour des langages normalises, et pour des formats de description de fichiers divers.

Pour ces derniers (ou en fait la mode de nos jours serait d'utiliser du XML, mais ils ont un historique predatant XML -- XML decrit directement l'AST, si on fait un langage on va essayer d'etre plus lisible), les generateurs sont interessants. Parce que le format est sous notre controle (et donc qu'on peut choisir de ne pas et que l'adequation de la grammaire avec le generateur est donc garantie. C'est ce que j'apellais la complexite moyenne.

Pour les langages, les generateurs sont plutot une gene: ils facilitent un peu les 80% du boulot le plus facile mais rende encore plus penible les 20% restant (les parties du langage non LALR et sortir des messages d'erreur d'une qualite convenable, en particulier quand on veut un parseur unique pour traiter -- les generateurs GLR sont une solution pour le premier point, mais je n'ai aucune indication qu'il y ait une solution convenable avec des generateurs pour le second). C'est pas un hasard si gcc a laisser tomber les generateurs pour le C et le C++ et n'en a jamais utilise de generateur pour Ada (il me semble que c'est le cas de clang aussi).

Pour quelque chose de simple comme des expressions, en fait n'importe quoi qui est familier est préférable a quelque chose de pas familier. Mais un programmeur pas familier avec les techniques pour les écrire a la main a un trou dans sa formation.

[jblecanard]

Pour quelque chose de simple comme des expressions, en fait n'importe quoi qui est familier est préférable a quelque chose de pas familier. Mais un programmeur pas familier avec les techniques pour les écrire a la main a un trou dans sa formation.

J'admire ton expertise en la matière, mais je ne crois pas que savoir écrire proprement un parseur, même simple, soit à classer dans les techniques de base. Il y a quand même pas mal de notions formelles que beaucoup de programmeurs ne connaissent pas. J'ai pas mal étudié ça en cours et je ne m'en rapelle clairement pas assez pour écrire sereinement un parseur propre. Il faudrait que je réétudie les techniques.

Sinon, si on applique ton avis sur l'interpréteur que suis en train de fignoler, je pense que j'arrive pile dans la marge ou ça me fait bien plaisir d'avoir un générateur et où je n'ai pas besoin de me battre avec ses limites.

[jblecanard]

Messieurs, voici enfin mon interpréteur, j'espère qu'il va vous plaire. Vous le trouverez sur GitHub.

@Jean-Marc : Je ne sais pas si tu as déjà essayé spirit entre autres générateurs, mais je l'ai trouvé bien plus simple à utiliser (de très loin) que les 2 ou 3 que j'ai rencontrés par le passé.

Plutôt que d'aller directement lire le code, qui risque d'être imbitable au premier abord, je vous invite à lire le Main.cpp qui contient tous les exemples nécessaires à sa compréhension et à son utilisation. Ne vous y fiez pas, il y a quelques subtilités de bon aloi . Le code de l'outil en lui même fait 200 lignes à tout casser, tout compris.

[Goten]

Messieurs, voici enfin mon interpréteur, j'espère qu'il va vous plaire. Vous le trouverez sur GitHub.

@Jean-Marc : Je ne sais pas si tu as déjà essayé spirit entre autres générateurs, mais je l'ai trouvé bien plus simple à utiliser (de très loin) que les 2 ou 3 que j'ai rencontrés par le passé.

Plutôt que d'aller directement lire le code, qui risque d'être imbitable au premier abord, je vous invite à lire le Main.cpp qui contient tous les exemples nécessaires à sa compréhension et à son utilisation. Ne vous y fiez pas, il y a quelques subtilités de bon aloi . Le code de l'outil en lui même fait 200 lignes à tout casser, tout compris.

T'es allergique à boost.function?

[jblecanard]

T'es allergique à boost.function?

Pas du tout, pourquoi donc ? Je n'ai pas ressenti de besoin mais si ça peut me faire gagner encore en poids et en flexibilité, je vais regarder. Je suis encore débutant avec Boost, j'ai codé ça en guise d'exercice...

Edit : En effet, ça peut économiser un héritage un peu lourdingue. Pour la prochain "release" donc
Edit 2 :
- Pour la suite de l'évolution de l'outil, c'est ici.
- Pour la suite de l'évolution de l'éventuel tuto, c'est là.

[Jean-Marc.Bourguet]

J'admire ton expertise en la matière, mais je ne
crois pas que savoir écrire proprement un parseur, même simple, soit à
classer dans les techniques de base. Il y a quand même pas mal de notions
formelles que beaucoup de programmeurs ne connaissent pas. J'ai pas mal
étudié ça en cours et je ne m'en rapelle clairement pas assez pour écrire
sereinement un parseur propre. Il faudrait que je réétudie les techniques.

Je diagnostique un cours trop basé sur la théorie accompagné de pas assez
de pratique. Je ne pense pas être expert en la matière (j'ai trop de trous
dans mes connaissances pour l'être, en commencant par tout ce qui s'est
fait les 10 dernières années, mais même il y a 10 ans j'étais expérimenté
mais pas expert) et la technique que j'ai utilisée est loin d'être une
technique d'expert. Si j'avais à donner un cours sur les compilateurs, je
l'introduirais plutôt avec une phrase du genre "si vous ne devez retenir
qu'une chose, c'est cette technique".

Sinon, si on applique ton avis sur l'interpréteur que suis en train
de fignoler, je pense que j'arrive pile dans la marge ou ça me fait bien
plaisir d'avoir un générateur et où je n'ai pas besoin de me battre avec
ses limites.

C'est pas mon avis. Plus loin tu déclares:

Ne vous y fiez pas, il y a quelques subtilités de
bon aloi . Le code de l'outil en lui même fait 200 lignes à tout
casser, tout compris.

Pour rappel, le code que je donnais fait 150 lignes. Si on lui enlève le
traitement particulier de sin et cos et ajoute le traitement de
l'exponentiation et des fonctions en général, on ne va pas être très loin
de 200 lignes (mais plutôt de l'autre côté, je suis d'accord) de C pur,
sans subtilités. Même si on double pour avoir une encapsulation correcte
en C++, je ne suis pas convaincu du tout que ça vaille la peine de tirer
tout Spirit. Je suis certain que ça ne vaut pas la peine d'apprendre
Spirit pour ça.

Plutôt que d'aller directement lire le code, qui risque d'être
imbitable au premier abord,

Moi j'invite à lire mon code, j'espère qu'il n'est pas imbitable, même non
documenté, même sans avoir eu un exposé sur la technique utilisée

@Jean-Marc : Je ne sais pas si tu as déjà essayé spirit entre autres
générateurs, mais je l'ai trouvé bien plus simple à utiliser (de très loin)
que les 2 ou 3 que j'ai rencontrés par le passé.

Je n'ai rien contre les générateurs (je n'en aurais pas écrit sinon). Je
pense simplement qu'ils sont trop souvent utilisés en dehors de leur zone
de pertinence parce qu'on ne présente pas assez les alternatives. En
passant, un avantage des générateurs que je n'ai pas donné plus haut est
que quand ils acceptent la grammaire de référence sans modification, ils
offrent une garantie très forte de ne pas accepter un autre langage que
celui de la grammaire.

J'ai déjà regardé Spirit et je vois plus ou moins comment il fonctionne
(c'est à dire que je vois très bien comment je ferais fonctionner qqch de
semblable, mais comme il y a un certain nombre d'alternatives possibles, je
ne sais pas les quelles ont été choisies). Je ne l'ai jamais utilisé mais il fait partie des options que j'explorerai plus en détail si le besoin s'en fait sentir.

[jblecanard]

Quand je parle de code imbitable, c'est pour qui ne connaît rien de boost
Quand je parle de petite subtilités, c'est sur mon choix de l'interface C++ par sur le code derrière, qui est somme toute assez simple pour un utilisateur de boost expérimenté.

Je comprend ton avis : le coût d'apprentissage de Spirit + le codage revient au même (ou coûte plus cher) que le faire à la main. On est pas à centaine de lignes près d'ailleurs si tu ne tires sur rien.

Moi je me place dans un autre contexte : je pars du principe que je connais Spirit et que je n'ai que le coût de dev. Parce que l'apprentissage pourra me resservir plus tard, et c'est là que le temps sera gagné. Dans un contexte professionnel ou tu es serré sur le temps, mon point de vue ne marche pas. Mais ce n'est pas mon cas ici, et mon code pourra resservir à d'autres, un tirage sur boost (headers only) n'étant pas très cher.

[Jean-Marc.Bourguet]

Je comprend ton avis : le coût d'apprentissage de Spirit + le codage revient au même (ou coûte plus cher) que le faire à la main. On est pas à centaine de lignes près d'ailleurs si tu ne tires sur rien.

Je parle meme hors du cout d'apprentissage. Si j'ai le choix entre ecrire 300 lignes de code simple ou ecrire 200 lignes et ajouter une dependance, je ne vais pas ajouter de dependance, meme si je sais deja me servir de la dependance; je ne l'utiliserais probablement pas meme si la dependance est deja utilisee dans un autre contexte dans le projet.

Il n'y a que trois raisons qui me feraient utiliser autre chose qu'un parseur ecrit a la main pour un evaluateur d'expression comme le tien:
- je prevois de le faire evoluer vers un langage plus complet;
- c'est un exercice de style ou d'apprentissage d'un generateur ou d'une lib du genre Spirit;
- c'est impose par ma hierarchie en depit de mon avis contraire.

Moi je me place dans un autre contexte : je pars du principe que je connais Spirit et que je n'ai que le coût de dev. Parce que l'apprentissage pourra me resservir plus tard, et c'est là que le temps sera gagné. Dans un contexte professionnel ou tu es serré sur le temps, mon point de vue ne marche pas. Mais ce n'est pas mon cas ici, et mon code pourra resservir à d'autres, un tirage sur boost (headers only) n'étant pas très cher.

Dans mon contexte professionnel, il y a les questions du genre "est-ce que ca vaut la peine de faire intervenir le departement legal pour valider l'utilisation de la lib?", "qu'est-ce qu'on fait si la lib a un bug?", "est-ce que ca vaut la peine de devoir se coordonner avec les autres equipes lors des mises a jour de la lib?", "est-ce qu'on est raisonnablement sur d'avoir la lib maintenue dans 10 ans?", "est-ce que c'est sense de demander a ceux qui vont maintenir le code -- ca fini toujours par etre d'autres personnes que ceux qui l'on développé -- de connaitre/apprendre la lib?"

[jblecanard]

- c'est un exercice de style ou d'apprentissage d'un generateur ou d'une lib du genre Spirit

C'est exactement mon cas

Dans mon contexte professionnel, il y a les questions du genre "est-ce que ca vaut la peine de faire intervenir le departement legal pour valider l'utilisation de la lib?", "qu'est-ce qu'on fait si la lib a un bug?", "est-ce que ca vaut la peine de devoir se coordonner avec les autres equipes lors des mises a jour de la lib?", "est-ce qu'on est raisonnablement sur d'avoir la lib maintenue dans 10 ans?", "est-ce que c'est sense de demander a ceux qui vont maintenir le code -- ca fini toujours par etre d'autres personnes que ceux qui l'on développé -- de connaitre/apprendre la lib?"

100% d'accord, chacun fait en fonction de ses contraintes. Ce n'est pas forcément compliqué si Boost est déjà dans le projet. Mon code est libre de droit, celui de ne pas l'utiliser compris

[Jean-Marc.Bourguet]

C'est exactement mon cas

C'est bien ce que j'avais compris. Je suis intervenu parce que personne ne proposait a l'OP autre chose que l'utilisation de generateur ou de lib generique, et que c'est le cas a chaque fois qu'on cause de parsing.