Je faisais des recherches sur la suite du compilateur gcc sur wikipedia ici , quand cela a été annoncé:
GCC a commencé par utiliser des analyseurs LALR générés avec Bison, mais a progressivement adopté des analyseurs manuscrits à descente récursive; pour C ++ en 2004 et pour C et Objective-C en 2006. Actuellement, tous les frontaux utilisent des analyseurs syntaxiques à descente récursive écrits à la main.
Donc, par cette dernière phrase (et pour autant que je me fie à wikipedia), je peux définitivement dire que "C (gcc), C ++ (g ++), Objective-C, Objective-C ++, Fortran (gfortran), Java (gcj), Ada (GNAT), Go (gccgo), Pascal (gpc), ... Mercury, Modula-2, Modula-3, PL / I, D (gdc) et VHDL (ghdl) "sont tous des interfaces qui ne plus utiliser un générateur d'analyseur. C'est-à-dire qu'ils utilisent tous des analyseurs syntaxiques écrits à la main.
Ma question est alors, est-ce que cette pratique est omniprésente? Plus précisément, je cherche des réponses exactes à "l'implémentation standard / officielle de x a-t-elle un analyseur manuscrit" pour x dans [Python, Swift, Ruby, Java, Scala, ML, Haskell]? (En fait, les informations sur les autres langues sont également les bienvenues ici.) Je suis sûr de pouvoir le trouver moi-même après de nombreuses recherches. Mais je suis également sûr que la communauté peut facilement répondre à cette question. Merci!
Réponses:
D’après les informations dont nous disposons, GCC utilise des analyseurs syntaxiques écrits à la main, en particulier, pour améliorer le diagnostic des erreurs syntaxiques (c’est-à-dire donner des messages humains significatifs sur les erreurs de syntaxe).
La théorie de l'analyse syntaxique (et les générateurs d'analyse descendants de celle-ci) consiste principalement à reconnaître et à analyser une phrase d'entrée correcte . Mais nous attendons des compilateurs qu'ils donnent un message d'erreur significatif (et qu'ils soient capables d'analyser de manière significative le reste de l'entrée après l'erreur syntaxique), pour certaines entrées incorrectes.
En outre, les anciens langages hérités, comme C11 ou C ++ 11 (qui sont conceptuellement anciens, même si leur dernière révision date de trois ans) ne sont pas du tout dépourvus de contexte. Faire face à cette sensibilité au contexte dans les grammaires pour les générateurs d’analyseurs (c’est-à-dire le bison ou même le menhir ) est ennuyeux.
la source
Dealing with that context sensitiveness in grammars for parser generators is boringly difficult. C'est aussi plus ou moins impossible, car ces outils génèrent des analyseurs syntaxiques sans contexte. Le bon endroit pour vérifier si toutes les contraintes contextuelles sont présentes est après avoir généré l'arbre d'analyse syntaxique si vous utilisez des outils comme celui - ci.Les générateurs et moteurs d'analyse sont assez généraux. L’avantage de la généralité est qu’il est facile, dans l’ensemble, de créer rapidement un analyseur précis et de le rendre fonctionnel.
Le moteur de l'analyseur lui-même souffre sur le plan des performances en raison de sa généralité. Tout code manuscrit sera toujours beaucoup plus rapide que les moteurs d’analyse par table.
Le deuxième domaine qui pose problème aux générateurs / moteurs d'analyse est que tous les langages de programmation sont sensibles au contexte, souvent de manière assez subtile. Les langues LR sont dépourvues de contexte, ce qui signifie qu'il existe de nombreuses subtilités concernant le positionnement et l'environnement qui sont impossibles à transmettre correctement dans la syntaxe. Les grammeurs attribués tentent de traiter des règles de base du langage, telles que "déclarer avant utilisation", etc. Le câblage de cette sensibilité au contexte dans du code manuscrit est simple.
la source