Che cos'è un parser IELR (1)?

Cerco di insegnarmi come usare il bisonte. La manpage bison (1) dice del bisonte:

Genera un parser LR deterministico o LR generalizzato (GLR) utilizzando le tabelle di parser LALR (1), IELR (1) o LR canonico (1).

Che cos'è un parser IELR? Tutti gli articoli pertinenti che ho trovato sul World Wide Web sono dotati di paywall.

— FUZxxl
fonte

Compreso cs.clemson.edu/~malloy/papers/sac08/paper.pdf ?

— reinierpost,

@reinierpost Mi sento così stupido in questo momento. Perché non l'ho trovato?

— FUZxxl,

Non lo so - Google personalizza i risultati ...

— reinierpost il

@reinierpost, vuoi rispondere a questa domanda citando il tuo link, in modo da ripulire questa domanda ?

— Merbs,

Hmmm ... se è tutto ciò che serve, OK.

— reinierpost,

Risposte:

L'algoritmo di analisi IELR (1)

L' algoritmo di analisi IELR (1) è stato sviluppato nel 2008 da Joel E. Denny nell'ambito del suo dottorato di ricerca. ricerca sotto la supervisione di Brian A. Malloy alla Clemson University. L'algoritmo IELR (1) è una variante del cosiddetto algoritmo LR (1) "minimo" sviluppato da David Pager nel 1977 , che a sua volta è una variante dell'algoritmo di analisi LR (k) inventato da Donald Knuth nel 1965 . L'IE in IELR (1) significa eliminazione inadeguata (vedere l'ultima sezione).

Algoritmi LR (1)

La LR (1) parte di IELR (1) significa L eft a destra, R ightmost derivazione con 1 lookahead token. I parser LR (1) sono anche chiamati parser canonici. Questa classe di algoritmi di analisi impiega una strategia di analisi bottom-up, shift-shift con una tabella di transizione dello stack e dello stato che determina l'azione successiva da eseguire durante l'analisi.

Storicamente, gli algoritmi LR (1) sono stati svantaggiati da grandi requisiti di memoria per le loro tabelle di transizione. Il miglioramento di Pager è stato lo sviluppo di un metodo per combinare gli stati di transizione quando viene generata la tabella di transizione, riducendo significativamente le dimensioni della tabella. Pertanto l'algoritmo di Pager rende i parser LR (1) competitivi con altre strategie di analisi rispetto all'efficienza di spazio e tempo. La frase "parser LR (1) minimo" si riferisce alla dimensione minima della tabella di transizione introdotta dall'algoritmo di Pager.

Limitazioni dell'algoritmo di Pager

Gli algoritmi LR (1) minimi producono la tabella di transizione basata su una particolare grammatica di input per la lingua da analizzare. Diverse grammatiche possono produrre la stessa lingua. In effetti, è possibile che una grammatica non LR (1) produca un linguaggio analizzabile LR (1). In pratica, i generatori di parser LR (1) accettano grammatiche non LR (1) con una specifica per la risoluzione dei conflitti tra due possibili transizioni di stato ("conflitti di riduzione del cambio") per adattarsi a questo fatto. Denny e Malloy hanno scoperto che l'algoritmo di Pager non riesce a generare parser abbastanza potente da analizzare le lingue LR (1) quando vengono fornite determinate grammatiche non LR (1) anche se la grammatica non LR (1) genera una lingua LR (1).

Denny e Malloy dimostrano che questa limitazione non è semplicemente accademica dimostrando che Gawk e Gpic, entrambi software molto diffusi e maturi, eseguono azioni errate del parser.

Miglioramenti di IELR (1)

Denny e Malloy hanno studiato l'origine delle carenze dell'algoritmo di Pager confrontando la tabella di transizione generata dall'algoritmo di Pager con la tabella di transizione di una grammatica LR (1) equivalente e identificato due fonti di quelle che definiscono inadeguate che appaiono nella tabella di transizione da Pager algoritmo ma non nella tabella di transizione LR (1). L'algoritmo IELR (1) ( Inadequacy Elimination LR (1)) di Denny and Malloy è un algoritmo progettato per eliminare queste inadeguatezze quando si genera una tabella di transizione di dimensioni praticamente identiche a quella dell'algoritmo di Pager.

— Robert Jacobson
fonte

Un articolo che afferma di presentarlo: IELR (1): Practical LR (1) Parser Tables for Non-LR (1) Grammars with Conflict Resolution (via archive.org) di Joel E. Denny e Brian A. Malloy, Clemson University , è disponibile gratuitamente dal sito di Malloy.

Quello che valgono è qualcosa a cui non posso rispondere. (Personalmente non capisco la necessità di tale analisi paralizzante del CFG - perché limitare il tuo potere espressivo quando puoi semplicemente usare GLR ? Ciò che ha senso per me è qualcosa come TAG o PEG (sembrano naturali e aggiungono potere espressivo) o albero grammatiche (per linguaggi come XML, in cui il riconoscimento degli alberi di analisi non ha problemi di progettazione).

— reinierpost
fonte

Sebbene io sia d'accordo sul principio della tecnologia, spesso il problema è che l'analisi tradizionale deterministica ha implementazioni migliori e più complete. Un altro problema è che l'analisi del CF generale è più potente, ma GLR potrebbe non essere la versione migliore di esso.

— babou,

Il motivo principale per cui le persone hanno sviluppato parser CFG zoppicanti è che un parser GLR non funziona necessariamente in un tempo lineare, questo è un grosso problema per molte applicazioni. Un parser IELR può garantire un runtime lineare e altro.

— FUZxxl

Non capisco perché sarebbe un problema.

— reinierpost,

O (n^{4})

$O(n^4)$

O (n^{3})

$O(n^3)$

l i m_{x \to \infty} O (n^{x})

$lim_{x\rightarrow\infty} O(n^x)$ . Gli umani non vivono per sempre e hanno molto da fare. Perdere tempo è generalmente negativo.

— utente

Vorrei sottolineare che "Personalmente non capisco la necessità di analisi paralizzate del CFG: perché limitare il tuo potere espressivo quando puoi semplicemente usare GLR?" è piuttosto fuorviante in questo contesto. IELR (1) viene utilizzato per generare tabelle di parser LR (1) più efficienti , che consentono parser GLR più efficienti .

— orlp