L'analisi separata e i passaggi di lexing sono buone pratiche con i combinatori di parser?

Quando ho iniziato a usare i combinatori parser la mia prima reazione è stata un senso di liberazione da quella che sembrava una distinzione artificiale tra analisi e lexing. All'improvviso tutto stava solo analizzando!

Tuttavia, recentemente mi sono imbattuto in questo post su codereview.stackexchange che illustra qualcuno che ripristina questa distinzione. All'inizio ho pensato che fosse molto sciocco da parte loro, ma poi il fatto che in Parsec esistano funzioni per supportare questo comportamento mi porta a interrogarmi.

Quali sono i vantaggi / gli svantaggi dell'analisi su un flusso già lessato nei combinatori parser?

Sotto analisi comprendiamo molto spesso l'analisi dei linguaggi liberi dal contesto. Un linguaggio privo di contesto è più potente di un normale, quindi il parser può (molto spesso) fare immediatamente il lavoro dell'analizzatore lessicale.

Ma questo è a) abbastanza innaturale b) spesso inefficiente.

Per a), se penso a come ifappare un'espressione, penso che SE ESPR POI ESPR ELSE expr e non 'i' 'f', forse alcuni spazi, allora qualsiasi carattere con cui un'espressione può iniziare, ecc. Ottieni idea.

Per b) esistono potenti strumenti che fanno un ottimo lavoro riconoscendo entità lessicali, come identificatori, valori letterali, parentesi di ogni tipo, ecc. Faranno il loro lavoro praticamente in pochissimo tempo e ti daranno una bella interfaccia: un elenco di token. Non preoccuparti più di saltare gli spazi nel parser, il tuo parser sarà molto più astratto quando si tratta di token e non di personaggi.

Dopotutto, se pensi che un parser dovrebbe essere impegnato con cose di basso livello, perché quindi elaborare i caratteri? Si potrebbe scrivere anche a livello di bit! Vedete, un tale parser che funziona a livello di bit sarebbe quasi incomprensibile. È lo stesso con personaggi e gettoni.

Solo i miei 2 centesimi.

Tutti suggeriscono che separare il lex e il parsing sia una "buona pratica" - devo essere in disaccordo - in molti casi eseguire il lex e il parsing in un singolo passaggio dà molta più potenza e le implicazioni sulle prestazioni non sono così negative come sono presentate nel altre risposte (vedi Packrat ).

Questo approccio brilla quando si devono mescolare un numero di lingue diverse in un singolo flusso di input. Ciò non è necessario solo per gli strani linguaggi orientati alla metaprogrammazione come Katahdin e simili , ma anche per applicazioni molto più tradizionali, come la programmazione alfabetica (mescolando lattice e, diciamo, C ++), usando HTML nei commenti, inserendo Javascript in HTML e presto.

Un analizzatore lessicale riconosce un linguaggio regolare e un parser riconosce un linguaggio privo di contesto. Poiché ogni linguaggio regolare è anche privo di contesto (può essere definito da una cosiddetta grammatica lineare destra ), un parser può anche riconoscere un linguaggio regolare e la distinzione tra parser e analizzatore lessicale sembra aggiungere una complessità non necessaria: un singolo contesto grammatica libera (parser) potrebbe fare il lavoro di un parser e di un analizzatore lessicale.

D'altra parte, può essere utile catturare alcuni elementi di un linguaggio privo di contesto attraverso un linguaggio regolare (e quindi un analizzatore lessicale) perché

1. Spesso questi elementi appaiono così spesso che possono essere trattati in modo standard: riconoscere letterali di numeri e stringhe, parole chiave, identificatori, saltare gli spazi bianchi e così via.
2. La definizione di un linguaggio regolare di token rende più semplice la grammatica risultante senza contesto, ad esempio si può ragionare in termini di identificatori, non in termini di singoli caratteri, oppure si può ignorare completamente lo spazio bianco se non è rilevante per quel particolare linguaggio.

Quindi separare l'analisi dall'analisi lessicale ha il vantaggio di poter lavorare con una grammatica più semplice senza contesto e incapsulare alcune attività di base (spesso di routine) nell'analizzatore lessicale (divide et impera).

MODIFICARE

Non ho familiarità con i combinatori di parser, quindi non sono sicuro di come le considerazioni precedenti si applichino in quel contesto. La mia impressione è che anche se con i combinatori di parser si ha solo una grammatica senza contesto, distinguere tra due livelli (analisi lessicale / analisi) potrebbe aiutare a rendere questa grammatica più modulare. Come detto, il livello inferiore di analisi lessicale potrebbe contenere parser riutilizzabili di base per identificatori, valori letterali e così via.

Semplicemente, il lessico e l'analisi dovrebbero essere separati perché sono diverse complessità. Il Lexing è un DFA (automa finito deterministico) e un parser è un PDA (automa push-down). Ciò significa che l'analisi intrinsecamente consuma più risorse del lexing e ci sono tecniche di ottimizzazione specifiche disponibili solo per i DFA. Inoltre, scrivere una macchina a stati finiti è molto meno complesso ed è più facile da automatizzare.

Stai sprecando usando un algoritmo di analisi per Lex.

Uno dei principali vantaggi dell'analisi separata / lex è la rappresentazione intermedia: il flusso di token. Questo può essere elaborato in vari modi che altrimenti non sarebbero possibili con un lex / parse combinato.

Detto questo, ho scoperto che un buon decorso ricorsivo può essere meno complicato e più facile da lavorare rispetto all'apprendimento di un generatore di parser, e dover capire come esprimere la debolezza della grammatica all'interno delle regole del generatore di parser.