2010-04-27 16 views
5

Estoy evaluando el uso de Coco/R frente a ANTLR para usar en un proyecto de C# como parte de lo que es esencialmente una funcionalidad de fusión de correos programable. Para analizar las secuencias de comandos (simples), necesitaré un analizador .Coco/R frente a ANTLR

Me he centrado en Coco/R y ANTLR porque ambos parecen bastante maduro y bien mantenido y capaz de generar analizadores C# decentes.

Tampoco parece ser trivial para utilizar, sin embargo, y simplicidad es algo que apreciaría - particularmente mantenimiento por otros.

¿Alguien tiene alguna recomendación que hacer? ¿Cuáles son los pros/contras de un análisis de un lenguaje pequeño o estoy investigando las cosas incorrectas por completo? ¿Qué tan bien se integran en una configuración típica de integración continua? ¿Cuáles son las trampas?

relacionadas: Bueno, muchas preguntas, tales como 1, 2, 3, 4, 5.

Respuesta

1

Si simplemente está fusionando datos en una plantilla complicada, considere Terence Parr's StringTemplate engine. Él es el hombre detrás de ANTLR. StringTemplate puede ser más adecuado y más fácil de usar que un generador de analizador completo. Es un motor de plantillas con muchas funciones.

Hay un puerto C# disponible en el downloads.

+0

Vi eso, ¿no lo habrías probado? Estoy un poco receloso de usar un puerto potencialmente mal probado. –

+0

@Earnon Nerbonne: Lo he utilizado en un proyecto de prueba de concepto sin ningún problema, pero no he podido comentar qué tan bien se ha probado. Buena suerte. –

+0

Esta respuesta puede que realmente no haya cubierto mis necesidades, pero sin duda es un punto de partida, y eso la convierte en la mejor respuesta para mí :-). –

2

Básicamente, coco/r genera analizadores de descenso recursivo y solo es compatible con las gramáticas LL (1) mientras que ANTLR utiliza el seguimiento (entre otras técnicas), lo que le permite manejar gramáticas más complejas. Los analizadores coco/r son mucho más livianos y fáciles de comprender y desplegar, pero a veces es difícil conseguir la gramática en una forma que coco/r entiende dada su limitación de mirar hacia delante - para muchas gramáticas comunes del lenguaje de programación (p. ej. C++, SQL), no es posible en absoluto.

+4

La restricción LL (1) en CoCo no es tan grave. Puede agregar controladores de código para los casos en los que necesita desambiguar. –

+1

ANTLR no produce analizadores de desplazamiento-reducción. Eso sería un analizador LR mientras que ANTLR produce analizadores LL. –

+0

@Fernando Gonzalez Sanchez: Gracias, sí, lo he descubierto desde entonces, pero olvidé esta respuesta: voy a editar. –

3

ANTLR es LL (*), que es tan poderoso como PEG, aunque generalmente es mucho más eficiente y flexible. LL (*) degenera a LL (k) para k> 1, no es necesario realizar una búsqueda arbitraria.

+0

¿Es posible evitar el uso de un escáner en ANTLR? Estoy un poco preocupado por su mantenimiento porque el conjunto de tokens viables puede depender de las reglas gramaticales activas (es decir, como palabras clave condicionales como "de" en C#). –

+1

Claro. Pase cualquier objeto que implemente TokenStream. –

4

Hemos usado Coco durante 2 años, después de haber reemplazado a Antler que estábamos usando anteriormente. Para una consulta típica de big-data (nuestra aplicación), nuestra experiencia ha sido esta. Advertencia: dependemos del manejo completo de Utf-8, con el analizador implementado en C++. Estos números son para un lenguaje que tiene unas 200 producciones EBNF.

  • Cuerno: 260 usecs/consulta y una huella de memoria 108 MEGABYTE para el analizador generado/lexer
  • Coco: 220 usecs/consulta y una huella 70 KBYTE memoria para el analizador/escáner

Inicialmente, Coco tuvo un tiempo de arranque de 1.2 mseg y generó varias tablas de 60 KBYTE para mapear Utf-8. Hemos realizado muchas mejoras locales a Coco, como eliminar las tablas grandes, eliminar el tiempo de inicio de 1.2 ms, la documentación interna enormemente mejorada (así como la documentación en el código generado).

Nuestra versión de (fuente abierta) Coco tiene una huella pequeña comparada con Antlr y es muy más rápida, no tiene retraso de arranque y simplemente ... funciona. No tiene la agradable interfaz de usuario de Antler, pero nunca nos vino a la mente ser un problema una vez que comenzamos a usar Coco.

+1

Para ser un poco justos, debe permitir que el OP considere la mejora de ANTLR con el mismo nivel de inversión que ha realizado en CoCo. Teniendo en cuenta que su "aceleración" ajustada a mano es de aproximadamente 10-20%, parece estar al alcance, y escuché que ANTLR4 es más rápido que ANTLR3 de todos modos. La huella de memoria de 3 órdenes de magnitud es mucho más interesante; ¿Indagaron en dónde fue todo ese espacio? –