Coco/R vs ANTLR

Question

Sto valutando utilizzando Coco/R rispetto a ANTLR per l'utilizzo in un progetto C# come parte di ciò che è essenzialmente una funzionalità di unione della posta con script. Per analizzare gli script (semplici), ho bisogno di un parser .

Mi sono concentrato su Coco/R e ANTLR perché entrambi sembrano piuttosto maturi e ben curati e in grado di generare parser C# decenti.

Né sembrano essere banale da utilizzare, tuttavia, e la semplicità è qualcosa che farebbe piacere - in particolare manutenibilità da altri.

Qualcuno ha qualche raccomandazione da fare? Quali sono i pro/contro di entrambi per l'analisi di una lingua piccola - o sto esaminando completamente le cose sbagliate? Quanto bene si integrano in una tipica configurazione di integrazione continua? Quali sono le insidie?

correlate: Beh, molte domande, come ad esempio 1, 2, 3, 4, 5.

Answer 1

Se si fondono semplicemente i dati in un modello complesso, prendere in considerazione il numero StringTemplate engine di Terence Parr. È l'uomo dietro ANTLR. StringTemplate può essere più adatto e più facile da usare rispetto a un generatore di parser completo. È un motore di template molto ricco di funzionalità.

C'è una porta C# disponibile nello downloads.

Answer 2

Fondamentalmente, coco/r genera parsers di discesa ricorsivi e supporta solo grammatiche LL (1) mentre ANTLR utilizza il back-tracking (tra le altre tecniche), che gli consente di gestire grammatiche più complesse. I parser di coco/r sono molto più leggeri e più facili da comprendere e distribuire, ma a volte è una lotta ottenere la grammatica in una forma che coco/r capisce dato il suo vincolo di look-ahead - per molte grammatiche di programmazione comuni (ad es. C++, SQL), non è affatto possibile.

Answer 3

ANTLR è LL (*), che è potente come PEG, sebbene di solito molto più efficiente e flessibile. LL (*) degenera in LL (k) per k> 1 un lookahead arbitrario non è necessario.

Answer 4

Abbiamo usato Coco per 2 anni, avendo sostituito Antler che in precedenza usavamo. Per una tipica query su big data (la nostra applicazione), la nostra esperienza è stata questa. Avvertenza: dipendiamo dalla piena gestione di Utf-8, con il parser implementato in C++. Questi numeri sono per un linguaggio che ha circa 200 produzioni EBNF.

• Antler: 260 usecs/query e un'occupazione di memoria 108 MB per il parser generato/lexer
• Coco: 220 usecs/query e un ingombro 70 KBYTE memoria per il parser/scanner

Inizialmente, Coco aveva un tempo di avvio di 1,2 msec e generato diverse tabelle da 60 KBYTE per la mappatura di Utf-8. Abbiamo apportato molti miglioramenti locali a Coco, in modo da eliminare le tabelle di grandi dimensioni, eliminato il tempo di avvio di 1,2 msec, la documentazione interna notevolmente migliorata (oltre alla documentazione nel codice generato).

La nostra versione di (open source) Coco ha un ingombro minimo rispetto ad Antlr ed è molto più misurabile, non ha ritardo di avvio e ... funziona. Non ha la bella interfaccia utente di Antler ma non è mai entrato nella nostra mente di essere un problema una volta iniziato a utilizzare Coco.