Estaba investigando sobre el conjunto de compiladores gcc en wikipedia aquí , cuando surgió esto:
GCC comenzó usando analizadores LALR generados con Bison, pero gradualmente cambió a analizadores de descenso recursivo escritos a mano; para C ++ en 2004, y para C y Objective-C en 2006. Actualmente, todos los front-end utilizan analizadores de descenso recursivo escritos a mano
Entonces, en esa última oración, (y por mucho que confíe en wikipedia) definitivamente puedo decir 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) y VHDL (ghdl) "son todos los extremos que no Ya no use un generador de analizador. Es decir, todos usan analizadores escritos a mano.
Mi pregunta es, ¿es esta práctica omnipresente? Específicamente, estoy buscando respuestas exactas a "¿la implementación estándar / oficial de x tiene un analizador escrito a mano" para x en [Python, Swift, Ruby, Java, Scala, ML, Haskell]? (En realidad, la información en cualquier otro idioma también es bienvenida aquí.) Estoy seguro de que puedo encontrar esto por mi cuenta después de mucho excavar. Pero también estoy seguro de que esto es fácil de responder por la comunidad. ¡Gracias!
Respuestas:
AFAIK, GCC utilizan analizadores escritos a mano en particular para mejorar el diagnóstico de errores sintácticos (es decir, dar mensajes humanos significativos sobre errores de sintaxis).
La teoría de análisis (y los generadores de análisis que descienden de ella) se trata principalmente de reconocer y analizar una frase de entrada correcta . Pero esperamos de los compiladores que den un mensaje de error significativo (y que puedan analizar de manera significativa el resto de la entrada después del error sintáctico), por alguna entrada incorrecta.
Además, los lenguajes heredados antiguos, como C11 o C ++ 11, (que son conceptualmente antiguos, incluso si su última revisión tiene solo tres años) no están en absoluto libres de contexto. Tratar con esa sensibilidad al contexto en las gramáticas para los generadores de analizadores sintéticos (es decir, bisontes o incluso menhires ) es aburridamente difícil.
fuente
Dealing with that context sensitiveness in grammars for parser generators is boringly difficult. También es más o menos imposible ya que estas herramientas generan analizadores sin contexto. El lugar correcto para verificar si todas las restricciones sensibles al contexto están presentes es después de haber generado el árbol de análisis si está utilizando herramientas como esta.Los generadores del analizador y los motores del analizador son bastante generales. La ventaja de la generalidad es que construir un analizador preciso rápidamente y hacerlo funcional es fácil, en el esquema general de las cosas.
El motor de análisis en sí mismo sufre en el frente de rendimiento debido a su generalidad. Cualquier código escrito a mano siempre será significativamente más rápido que los motores de análisis de tablas.
La segunda área donde los generadores / motores analizadores tienen dificultades es que todos los lenguajes de programación reales son sensibles al contexto, a menudo de manera bastante sutil. Los lenguajes LR no tienen contexto, lo que significa que hay muchas sutilezas sobre el posicionamiento y el entorno que son imposibles de transmitir adecuadamente en la sintaxis. Los grammers atribuidos intentan abordar las reglas básicas del lenguaje como "declarar antes de usar", etc. El cableado de esta sensibilidad al contexto en código escrito a mano es sencillo.
fuente