Avantages d'Antlr (par rapport, disons, Lex / yacc / bison)
J'ai utilisé Lex et yacc (plus généralement le bison) dans le passé pour divers projets, généralement des traducteurs (comme un sous-ensemble d'EDIF diffusé dans une application EDA). De plus, j'ai dû prendre en charge du code basé sur des grammaires Lex/yacc datant de plusieurs décennies. Je connais donc bien les outils, même si je ne suis pas un expert.
J'ai vu des commentaires positifs sur Antlr dans divers forums dans le passé, et je suis curieux de savoir ce qui pourrait me manquer. Donc, si vous avez utilisé les deux, dites-moi ce qui est mieux ou plus avancé dans Antlr. Mes contraintes actuelles sont que je travaille dans une boutique C++, et tout produit que nous expédions n'inclura pas Java, donc les analyseurs résultants devraient suivre cette règle.
Mise à jour/avertissement: cette réponse est peut-être obsolète!
Une différence majeure est que ANTLR génère un analyseur LL (*), tandis que YACC et Bison génèrent tous deux des analyseurs qui sont LALR. Il s'agit d'une distinction importante pour un certain nombre d'applications, les plus évidentes étant les opérateurs:
expr ::= expr '+' expr
| expr '-' expr
| '(' expr ')'
| NUM ;
ANTLR est totalement incapable de gérer cette grammaire telle quelle. Pour utiliser ANTLR (ou tout autre générateur d'analyseur LL), vous devez convertir cette grammaire en quelque chose qui n'est pas récursif à gauche. Cependant, Bison n'a aucun problème avec les grammaires de cette forme. Vous devez déclarer "+" et "-" comme opérateurs associatifs à gauche, mais ce n'est pas strictement requis pour la récursion à gauche. Un meilleur exemple pourrait être l'envoi:
expr ::= expr '.' ID '(' actuals ')' ;
actuals ::= actuals ',' expr | expr ;
Notez que les règles expr et actuals sont récursives à gauche. Cela produit un AST lorsque vient le temps de générer du code car il évite d'avoir besoin de plusieurs registres et de déversements inutiles (un arbre de gauche peut être réduit alors qu'un arbre de droite ne peut pas ).
En termes de goût personnel, je pense que les grammaires LALR sont beaucoup plus faciles à construire et à déboguer. L'inconvénient est que vous devez faire face à des erreurs quelque peu cryptiques comme shift-réduire et (le redouté) réduire-réduire. Ce sont des erreurs que Bison détecte lors de la génération de l'analyseur, donc cela n'affecte pas l'expérience de l'utilisateur final, mais cela peut rendre le processus de développement un peu plus intéressant. ANTLR est généralement considéré comme plus facile à utiliser que YACC/Bison précisément pour cette raison.
La différence la plus significative entre YACC/Bison et ANTLR est le type de grammaires que ces outils peuvent traiter. YACC/Bison gère les grammaires LALR, ANTLR gère les grammaires LL.
Souvent, les personnes qui ont longtemps travaillé avec les grammaires LALR trouveront plus difficile de travailler avec les grammaires LL et vice versa. Cela ne signifie pas que les grammaires ou les outils sont intrinsèquement plus difficiles à travailler. L'outil que vous trouverez le plus facile à utiliser dépendra principalement du type de grammaire.
En ce qui concerne les avantages, il y a des aspects où les grammaires LALR ont des avantages sur les grammaires LL et il y a d'autres aspects où les grammaires LL ont des avantages sur les grammaires LALR.
YACC/Bison génèrent des analyseurs pilotés par table, ce qui signifie que la "logique de traitement" est contenue dans les données du programme d'analyseur, pas tellement dans le code de l'analyseur. Le résultat est que même un analyseur pour un langage très complexe a une empreinte de code relativement petite. Cela était plus important dans les années 1960 et 1970, lorsque le matériel était très limité. Les générateurs d'analyseurs pilotés par table remontent à cette époque et la petite empreinte de code était une exigence principale à l'époque.
ANTLR génère des analyseurs de descente récursifs, ce qui signifie que la "logique de traitement" est contenue dans le code de l'analyseur, car chaque règle de production de la grammaire est représentée par une fonction dans le code de l'analyseur. Le résultat est qu'il est plus facile de comprendre ce que fait l'analyseur en lisant son code. De plus, les analyseurs de descente récursifs sont généralement plus rapides que ceux pilotés par table. Cependant, pour les langages très complexes, l'empreinte du code sera plus grande. C'était un problème dans les années 60 et 70. À l'époque, seuls des langages relativement petits comme Pascal par exemple étaient implémentés de cette façon en raison de limitations matérielles.
Les analyseurs générés par ANTLR sont généralement proches de 10 000 lignes de code et plus. Les analyseurs de descente récursifs manuscrits sont souvent dans le même stade. Le compilateur Oberon de Wirth est peut-être le plus compact avec environ 4000 lignes de code, y compris la génération de code, mais Oberon est un langage très compact avec seulement environ 40 règles de production.
Comme quelqu'un l'a déjà souligné, un grand avantage pour ANTLR est l'outil graphique IDE, appelé ANTLRworks. C'est un laboratoire de conception de grammaire et de langage complet. Il visualise vos règles de grammaire lorsque vous les tapez et s'il détecte des conflits, il vous montrera graphiquement ce qu'est le conflit et ses causes. Il peut même refactoriser et résoudre automatiquement les conflits tels que la récursion à gauche. Une fois que vous avez une grammaire sans conflit, vous pouvez laisser ANTLRworks analyser un fichier d'entrée de votre langue et créez un arbre d'analyse et AST pour vous et affichez l'arbre graphiquement dans l'IDE. C'est un très grand avantage car cela peut vous faire économiser de nombreuses heures de travail: vous trouverez des erreurs conceptuelles dans votre conception de langage avant de commencer à coder! Je n'ai pas trouvé un tel outil pour les grammaires LALR, il semble qu'il n'y en ait pas.
Même pour les personnes qui ne souhaitent pas générer leurs analyseurs mais les coder manuellement, ANTLRworks est un excellent outil de conception/prototypage de langage. Probablement le meilleur outil de ce type disponible. Malheureusement, cela ne vous aide pas si vous souhaitez créer des analyseurs LALR. Passer de LALR à LL simplement pour profiter d'ANTLRworks peut bien être utile, mais pour certaines personnes, changer de type de grammaire peut être une expérience très douloureuse. En d'autres termes: YMMV.
Quelques avantages pour ANTLR:
- peut sortir des analyseurs dans différentes langues - Java non requis pour exécuter l'analyseur généré.
- Une interface graphique impressionnante facilite le débogage de la grammaire (par exemple, vous pouvez voir le droit AST généré dans l'interface graphique, aucun outil supplémentaire requis)
- Le code généré est en fait lisible par l'homme (c'est l'un des objectifs d'ANTLR) et le fait qu'il génère des analyseurs LL est certainement utile à cet égard.
- la définition des terminaux est également sans contexte (par opposition à l'expression régulière dans (f) Lex) - permettant ainsi, par exemple, la définition de terminaux contenant des parenthèses correctement fermées
Mon .02 $
Un autre avantage d'ANTRL est que vous pouvez utiliser ANTLRWORKS , bien que je ne puisse pas dire que c'est un avantage strict, car il peut y avoir des outils similaires pour d'autres générateurs ainsi que.
- Bison et Flex réduisent l'encombrement de la mémoire, mais vous n'avez pas d'IDE graphique.
- antlr utilise plus de mémoire, mais vous avez antlrworks, un IDE graphique.
L'utilisation de la mémoire Bison/Flex est généralement d'un octet ou plus. Comparez cela avec antlr - en supposant qu'il utilise 512 octets de mémoire pour chaque jeton du fichier que vous souhaitez analyser. 4 millions de jetons et vous n'avez plus de mémoire virtuelle sur un système 32 bits.
Si le fichier que vous souhaitez analyser est volumineux, antlr peut manquer de mémoire, donc si vous voulez simplement analyser un fichier de configuration, ce serait une solution viable. Sinon, si vous souhaitez analyser un fichier avec beaucoup de données, essayez Bison.