Motivi per usare le alternative lex/yacc?

Question

Circa una volta all'anno devo sviluppare o almeno progettare una grammatica e un parser - che appare una costante della mia vita lavorativa.

Ogni volta che sto affrontando questo compito, quindi circa una volta all'anno, io, piuttosto un ragazzo lex/yacc (flex/bison resp.), Considero, o riconsiderare, alternative per lex/yacc semplice, e, dopo un po ' meditando e provando, torno a lex/yacc.

perché ho un CORBA-server presso l'hub della richiesta posso chiamare da da un parser scritto in quasi tutte le lingue, quindi questa volta ho avuto uno sguardo al

• antlr4 (Java) e antlr3 (Java, ma ha RT per altre lingue),
• sablecc (Java),
• Parse :: EBNF, Parse :: Yapp e Marpa (Perl),
• e SimpleParse (Python),

Per me, il tandem antlr4 con antlrworks sembrava il candidato più promettente, ma non sono ancora convinto che il tempo speso per entrarci sarà ammortizzato alla fine.

---

La grammatica che devo sviluppare è simile a SQL DDL (in termini di struttura, non in termini di soggetto).

Perché una delle alternative renderebbe più semplice il mio compito rispetto all'utilizzo di lex/yacc semplice?

Answer 1

Quello che dovresti considerare è che diversi generatori di parser generano parser abbastanza diversi. Yacc/bison generano parser dal basso che sono spesso difficili da capire, difficili da debugare e dare strani messaggi di errore. Ad esempio, ANTLR produce un parser top-down discendente ricorsivo che è molto più semplice da comprendere,, è possibile eseguirne il debug facilmente (a meno che non si abbia un lexer 35MB come faccio io), è possibile utilizzare solo le sottoregole per un'operazione di analisi (ad es. espressioni di parsing invece del linguaggio completo).

Inoltre, il recupero degli errori è molto migliore e produce errori molto più chiari. C'è ANTLRWorks che è una grande app multipiattaforma per sviluppare ed eseguire il debug della grammatica (esegui il debug solo se utilizzi un target Java). Obiettivi Apropros: puoi generare parser in diverse lingue (C, C++, C#, Java e altro) dalla stessa grammatica, a meno che tu non abbia azioni specifiche della lingua nella tua grammatica (lo hai già detto nella tua domanda). E mentre parliamo di azioni: a causa del principio di valutazione nel parser di fondo (token di turno, token di turno, ridurle a un nuovo token e spostarlo ecc.) Le azioni possono facilmente causare problemi lì, ad es. eseguendo più di una volta e così via. Non così con i parser generati da ANTLR.

Ho anche provato vari generatori di parser nel corso degli anni, ho persino scritto il mio, ma vorrei comunque consigliare ANTLR come strumento di scelta.

Answer 2

Il latest Marpa is Marpa::R2, che ha grandi miglioramenti in "whipituptude", tra cui a very convenient new DSL interface, che è a sua volta scritto in Marpa. Potresti considerare di iniziare con Marpa, per "prototipazione". Marpa è altamente dichiarativo, usando BNF pulito. Se si esegue la migrazione, è possibile portare la maggior parte del lavoro al nuovo parser. Marpa è insuperato nella sua gestione e rilevamento degli errori, anche molto utile in una fase di prototipazione.

Marpa analizza tutte le classi di grammatica analizzate dagli altri parser elencati in tempo lineare ed è insuperabile nella sua flessibilità. La sua funzione più recente consente di passare da Marpa al proprio codice di analisi. Quindi potresti anche stare con esso. C'è a website, e il mio blog ha a series of tutorials, che potrebbe essere il modo migliore per farsi conoscere da Marpa.