Informatique

Hello

Quelqu'un ici s'y connais en EBNF ? J'ai une grammaire en EBNF, mais je suis pas sûr qu'elle soit correcte... Quelqu'un sait la vérifier et m'aider un peu?

Merci

Poste ta question ici directement.

Oui, effectivement ce sera plus simple.

Donc, je tente d'élaborer un langage de programmation, et j'ai rédigé ma grammaire, la voici ici sur Pastebin (les commentaires que j'ai rédigé sont en anglais, car je demande souvent de l'aide sur des forums anglophones plus spécialisé, mais personne n'as vraiment su m'aider)
https://pastebin.com/w5gbEAE6

J'ai utilisé l'EBNF, avec les opérateurs comme * pour désigner 0 ou + répétitions et ? pour désigner un non terminal facultatif.
Je pense qu'elle est quasi complète, elle devrait être relativement solide et savoir parser les conditions/expressions complexes comme :
((a==1) && (b==1)) || ((a==2) && (b==2))
Ou des expressions mathématiques qui incluent des appels de fonctions, des constantes brutes et des appels de variable, etc..

Voici des petits bouts de code simple qu'elle doit parser avec aisance. Je dois encore rédiger les bouts de code avec les boucles et les "edge-case" (où j'essaie de pousser le parsing d'expressions ou de conditions à ses limites). Je compte faire cela quand ma grammaire sera définitive.
https://pastebin.com/4H3fE072

Merci d'avance pour ton aide ^^

Je suis bête, j'ai écrit le message un peu vite :

Ma principale inquiétude c'est la robustesse de la grammaire au niveau du parsing et expressions & conditions.

Et ton doute viens de l'utilisation de '(' pour commencer une expression ey une condition, c'est ca ?

En C il n'y a pas de difference entre condition et expression ce qui regle le probleme..

Oui et non, ça ça va, car à l'implémentation la fonction parseExpr retournera faux vu qu'elle ne reconnaitra pas les symboles > < == et autres. Je suis plutot inquiet par rapport à la capacité de mes règles de grammaire à dériver une condition relativement complexe.

Mais passons à l'élément intéréssant :
Tu me dis qu'en C, les expressions et les conditions sont parsées par les mêmes règles (avec les opérateurs >< == et autre étant prioritaires et les opérateurs && et || moins prioritaires?) ?

Donc ma règle, qui parse tout en même temps ressemblerait à cela ?
https://pastebin.com/xRJt62fm

Je dois faire une distinction particulière entre les 2 à l'analyse sémantique ? Ou alors les noeuds représentant une condition sont juste des opérateurs mathématiques qui retournent 1 ou 0 selon si la condition est respectée ?

Et pour finir, si je fais aucune distinction, une formulation du genre
if((foo == 12) && (foo-11))
marcherait, car si foo est bien égal à 12 dans la première partie -> dans la seconde :12-11 sera égal à 1 (qui veut dire VRAI) et la condition du if est respecté? Ou le compilateur va me cracher dessus à l'analyse sémantique ?

EDIT : Je viens d'essayer et ça marche vraiment ! http://prntscr.com/gzei8w
Donc en fait, les conditions en C/C++ c'est juste "si le résultat de l'expression est égal à 1, alors :" ?
C'est fantastique et tellement ingénieux en même temps, j'adore ! :p

Donc en fait, les conditions en C/C++ c'est juste "si le résultat de l'expression est égal à 1, alors :" ?

Pas tout a fait. 0 est faux, et toutes les autres valeures sont vrai. Il se trouve juste que les operateurs logique retourne 0 ou 1.

C est un langage pragmatique. Meme au niveau du processeur d'ailleurs <, >, ==, |, || sont des operateurs comme +, - *

D'ailleurs souvent les operateurs conditionnel sont du type bnz, "branch if not equal zero"

Décidement, j'en apprend beaucoup ! Un grand merci à toi :p

Sinon le reste de ma grammaire tu y a jeté un oeil ? Qu'en penses tu ? Elle semble correcte?

J'ai tenté d'éviter au maximum la récursivité, j'ai toujours gardé en tête "est-ce que cette règle peut engendrer une boucle infinie" etc.. mais je sais pas si j'ai ignoré d'autres contraintes tout aussi importantes

D'ailleurs ca permet de faire des tricks rigolo. Par exemple

Au lieu de

if (a>b) x=a;

tu peux faire

x = (a>b)*a;

et au lieu de faire un test, un jump, une affectation, tu fais un test, et une multiplication. Tu gagnes une instruction et potentiellement une predictin de branchement qui se passe mal.

Note que ca n'a plus super cours sur des processeurs moderne. Mais c'est rigolo a savoir.

La grammaire m'a l'air correcte. Mais je l'ai lu avant le cafe, alors qui sait...

Ahah, je comprend ^^

C'est une grammaire de base aussi car je vise un "MVP" de mon langage avant tout. Je cherche pas à incorporer les trucs plus subtils (condiitons ternaires, enlever la nécéssité des accolades pour les block n'ayant qu'un seul statement, etc) ou les "types" avancés (pointeurs et références,tableaux), je compte les ajouter plus tard, que j'aurai débuggé complètement le "MVP"