generadores de analizadores sintácticos No necesidad de un escáner. Pero estás bastante loco si no usas uno.
Los analizadores creados por analizadores sintácticos no se preocupan por lo que los alimenta, siempre y cuando los llames tokens.
Para construir use un generador de analizador sintáctico sin un escáner, simplemente defina su gramática hasta el nivel de carácter y alimente los caracteres individuales al analizador como tokens.
La razón por la que esto es una locura es que el análisis sintáctico es una actividad más compleja que el léxico. Puede construir lexers como máquinas de estado finito, que se traducen en código de máquina más o menos como "comparar y saltar al siguiente estado". Para la velocidad, es realmente difícil de superar. Los generadores de analizadores construyen analizadores sintácticos que realizan un análisis predictivo de descenso recursivo (para la mayoría de los generadores LL como ANTLR) o realizan búsquedas de tabla mediante búsqueda hash, binaria o lineal, etc. Así que un analizador gasta mucha más energía en un token que un lexer gasta en un personaje.
Si alimenta caracteres a un analizador como tokens, gastará correspondientemente más energía en el carácter que el equivalente en lexer. Si procesa una gran cantidad de texto de entrada, esto eventualmente importará, ya sea que lo haga por tropecientos de flujos de entrada pequeños o unos pocos realmente grandes.
Los analizadores de GLR sin escáner sufren este problema de rendimiento, en relación con los analizadores GLR diseñados para usar tokens.
Mi empresa crea una herramienta, the DMS Software Reengineering Toolkit que utiliza un analizador GLR (y analiza con éxito todos los lenguajes comunes que conoce y muchos más extraños que no, porque tiene un analizador GLR). Sabíamos de analizadores sin escáner y elegimos no implementarlos debido a la diferencia de velocidad; tenemos un subsistema tipo LEX de estilo clásico (pero extremadamente poderoso) para definir tokens léxicos. En el único caso en el que el DMS pasó de punta a punta frente a una herramienta basada en XT (una herramienta sin un analizador GLR sin escáner) que procesaba la misma entrada, el DMS parecía ser 10 veces más rápido que el paquete XT. Para ser justos, el experimento realizado fue ad hoc y no se repitió, pero como coincidía con mis sospechas, no vi ninguna razón para repetirlo. YMMV. Y, por supuesto, si queremos ir sin escáner, bueno, es bastante fácil escribir una gramática con terminales de caracteres, como ya he señalado.
GLR analizadores sin escáner do tienen otra propiedad muy agradable que no le importará a la mayoría de las personas. Puede tomar dos gramáticas separadas para un analizador sin escáner, y literalmente concatenarlas, y obtener un analizador (a menudo con muchas ambigüedades). Esto importa mucho cuando construyes un lenguaje incrustado dentro de otro. Si eso no es lo que estás haciendo, esto es solo una curiosidad académica.
Y, AFAIK, Elkhound no es sin escáner. (Podría estar equivocado en esto). (EDIT: 2/10: Parece que estaba equivocado, no será la primera vez en mi vida :)
Algunos más "analizador de derivación de extremo derecho a extremo derecho a extremo" se enumeran aquí http://en.wikipedia.org/wiki/Comparison_of_parser_generators#Context-free_languages – stacker
@stacker: Wikipedia enumera el léxer de DParser como "generado"; Y GLR no implica que no haya ningún escáner – Meinersbur
No veo por qué un escáner sería un obstáculo para varios idiomas o idiomas sin palabras clave reservadas. El escáner aún sería útil para comer espacios en blanco y (al menos con frecuencia) comentarios, y concatenar personajes en números y palabras. –