Perché separare lex e analisi?

È possibile analizzare un documento utilizzando un singolo passaggio da una macchina a stati. Qual è il vantaggio di avere due passaggi, ad es. avere un lexer per convertire il testo in token e avere un parser per testare le regole di produzione su quei token? Perché non avere un unico passaggio che applica le regole di produzione direttamente al testo?

compilers parsers

— Brent
fonte

Correlati: programmers.stackexchange.com/questions/128888/…

— Utente

Questo è già stato discusso su CS, stackexchange, con molti commenti molto tecnici in una risposta al potere espressivo di lexer + parser . Ma potrebbe esserci spazio per ulteriori risposte.

— babou,

Mi chiedo se il parallelismo in stile pipeline (anche se fasi altamente squilibrate) potrebbe essere un vantaggio secondario. Anche il comportamento delle istruzioni e della cache dei dati potrebbe essere interessante. Quanto (se non del tutto) tale ridurrebbe i tempi di compilazione dipenderà dall'hardware specifico.

— Paul A. Clayton,

Una ragione abbastanza ovvia (almeno per me) è che puoi quindi usare lo strumento scanner separatamente. In pratica, utilizzo spesso il flex per scansionare l'input, ma raramente ho bisogno della piena potenza di yacc.

— jamesqf,

Non devi separarli. Le persone le combinano in parser senza scanner .

Lo svantaggio chiave dei parser senza scanner sembra essere che le grammatiche risultanti sono piuttosto complicate - più complicate della corrispondente combinazione di un'espressione regolare che fa lexing e una grammatica senza contesto che fa l'analisi sul flusso di token. In particolare, le grammatiche per l'analisi senza scanner tendono all'ambiguità. È più facile rimuovere l'ambiguità per le grammatiche che lavorano su un flusso di token.

Un vantaggio pragmatico dell'utilizzo di una fase di lexing iniziale dedicata è che non si accoppia il parser successivo con dettagli lessicali. Ciò è utile durante lo sviluppo iniziale del linguaggio di programmazione, quando i dettagli lessicali e sintattici continuano a cambiare frequentemente.

— Martin Berger
fonte

Avere un passaggio invece di due passaggi comporta proprietà di chiusura. Se si considera che i lexer sono trasduttori appartenenti a una famiglia formale

T

$T$ , che può essere combinato con parser appartenenti a una famiglia formale

P

$P$ , devi chiederti se comporli rimane nella stessa famiglia

P

$P$ o richiede una famiglia formale più complessa

P_{T}

$P_T$ , richiedendo quindi algoritmi diversi e un'accordatura forse più difficile della sintassi. La tecnologia di analisi si basa spesso su famiglie specializzate (come le varianti LR o LL) che potrebbero non avere le giuste proprietà di chiusura.

— babou,

@babou Sì, è corretto. Non conosco alcun risultato formale della forma espressione regolare composta con LL (k) esce da LL (k) o simile. Inoltre, il lessico di solito non viene fatto con le lingue normali, ma con qualcosa di più potente, vale a dire le lingue regolari estese con priorità di corrispondenza più lunghe e parole chiave. Non sono sicuro di quale esatta classe di lingua sia e quali siano le sue proprietà di chiusura.

— Martin Berger,

Se il tuo look-ahead implica la lettura di un identificatore, la composizione richiederà un look -bound senza limiti, poiché in linea di principio non vi è alcun limite alla lunghezza degli identificatori.

— babou,

@babou non ne sono sicuro. Se la parola chiave più lunga è lunga 17 caratteri, qualsiasi stringa più lunga deve essere un identificatore o lessicamente non valido.

— Martin Berger,

Ma il tuo identificatore, o possibilmente una stringa, un numero o un altro valore letterale, è una sequenza di più di 17 simboli individuali, che possono stare davanti al token di cui hai effettivamente bisogno. Questo è un grande sguardo avanti, senza limiti. Potresti finire con un linguaggio non deterministico.

— babou,