¿Qué ventajas tienen los analizadores LL sobre los analizadores LR?

GLR es genial si quieres un árbol/bosque de análisis y no te importan las cajas negras. Le permite escribir cualquier CFG que desee a costa de verificar ambigüedades en el momento del análisis mediante pruebas exhaustivas, en lugar de resolver los conflictos LR/LALR de forma estática. Algunos dicen que es una buena compensación. La herramienta DMS de Ira Baxter o Elkhound, que tiene una gramática gratuita de C++, son útiles para esta clase de problemas. ANTLR también es útil para una gran clase de aplicaciones de lenguaje, pero utiliza un aproximación, generando analizadores recursivos de descenso llamados LL (*) que permiten predicados semánticos. Declararé sin pruebas aquí que los predicados le permiten analizar lenguajes sensibles al contexto más allá de CFGs. A los programadores les gusta insertar acciones en gramáticas, como un buen manejo de errores y como depurar en un solo paso. LL es bueno en los tres. LL es lo que hacemos a mano para que sea más fácil de entender. No creas las tonterías de wikipedia sobre que LR es mejor manejando errores . Dicho esto, si usted retrocede mucho con ANTLR, los errores son de hecho peores con LL ( * ) (PEGs tienen este problema).

Volver atrás. GLR especula (es decir, backtracks) también, al igual que PEGs, ANTLR, y cualquier otra estrategia no determinista. En cualquier estado LR no determinista, GLR "bifurca" sub-analizadores para probar cualquier camino viable. De todos modos, LL tiene un buen contexto para el manejo de errores. Donde LR sabe que coincide con una expresión, LL sabe que es una expresión en una asignación o IF - condicional; LR sabe que podría estar en tampoco pero no está seguro, y esa incertidumbre es de donde obtiene su poder.

GLR es O(n^3) el peor caso. packrat / PEG es O(n) el peor caso. Los ANTLR son O(n^2) debido a lookahead cíclico DFA pero O(n) en la práctica. En realidad no importa. GLR es lo suficientemente rápido.

ANTLR es UNotros Tool para Lang Rel reconocimiento no anti-LR, pero eso me gusta demasiado ;)

Francamente, como muchos codificadores jóvenes en los 80, no entendía LALR y no me gustaban las cajas negras (ahora me gusta la belleza del motor GLR, pero todavía prefiero LL). Construí un compilador comercial basado en LL (k) y decidí construir una herramienta para generar lo que había construido a mano. ANTLR no es para todos y los casos extremos como C++ podrían manejarse mejor con GLR, pero mucha gente encuentra que ANTLR se adapta a su zona de confort. Desde enero de 2008, ha habido 134,000 descargas de jar binario de ANTLR, dentro de ANTLRWorks, y código fuente zips total (según Google Analytics). Ver nuestro artículo sobre LL(*) con muchos datos empíricos.