Come scegliere un generatore di parser adeguato per PHP

Question

Come scegliere un generatore di parser adeguato per PHP

#1 da (2 voti)

2

Alcuni programmatori evitano espressioni regex in alcune situazioni (vedi questo popolare commento @nickf ), forse usando un framework di analisi come Lex / Yacc . Altri preferiscono rimanere all'interno di PHP, magari usando espressioni regolari, in quanto evitano la necessità di un altro framework.

Quando dobbiamo usare un "vero" generatore di parser invece di codificare un parser direttamente in PHP?

Qual è il miglior kit di strumenti PHP per analizzare le cose complesse e quali fattori possono aiutarmi a determinare qual è il migliore?

Come di cui ho parlato prima , forse non esiste la soluzione migliore, ma semplicemente buone pratiche per aiutare a selezionare una soluzione.

NOTE

Leggi di seguito solo se sei uno scrittore di risposte

La mia domanda è stata modificata: ora ho un buon inglese e obiettività (!), grazie mille per @FrustratedWithFormsDesigner, @gnat e @Matt. Ma, forse con le editin di @Matt, ho perso il mio punto di vista.

Il mio punto non è una dicotomia "Regular expression vs. framework" (!).
Penso che (e vediamo esempi) che programmiamo PHP, abbiamo un buon "tool kit", non solo con espressioni regolari (vedi la potenza di preg_replace_callback ), funzioni di stringhe , ecc., per compiti di analisi semplici o molto specifici; ma anche con Manipolazione XML , per compiti complessi! Vedere de "parsing power" di elaborare con DOM e / o XSLT ...
Vedo anche casi in cui ho un dilemma sull'uso di questo "kit nativo per PHP", o sull'installazione e informazioni su qualche generatore di paser esterno (collegato come una libreria o una classe , ecc.).

php regular-expressions parsing

posta Peter Krauss 14.03.2013 - 15:52

fonte

1 risposta

Leggi altre domande sui tag php regular-expressions parsing

In un ambiente guidato dagli eventi, come dovrebbe una funzione "annulla" interrompere tutti gli altri eventi? Ruby manager per Windows: Rubik's PIK è vivo o sta morendo?

score 2 · Answer 1

Le espressioni regolari rispetto al quadro (nel senso di essere separate da una lingua) è una falsa dicotomia. Counter-esempio: combinatori di parser. Questi possono facilmente gestire linguaggi regolari, contestuali e sensibili al contesto; esistono delle belle librerie per loro in molte lingue. I principali vantaggi sono che l'integrazione linguistica consente loro di snarf le caratteristiche delle loro lingue ospitanti (come sistema di tipo, framework unit test, usando classi / oggetti / funzioni per estenderle, composabilità) e meno limitazioni come il token lookahead; i principali svantaggi sono che un'implementazione è legata a una lingua specifica (duh), i messaggi di errore decenti sono spesso difficili da generare e possono facilmente essere inefficienti se non si presta attenzione.

Ecco i fattori che osservo quando decido quale strumento utilizzare per analizzare qualcosa:

livello della lingua e dello strumento di analisi, sulla gerarchia di Chomsky. È una lingua normale? È privo di contesto? È sensibile al contesto? Se è sensibile al contesto, è meglio che il mio strumento di analisi possa gestirlo.
testabilità dei parser, inclusi quelli per le sotto-regole. È abbastanza facile creare parser che sembrano giusti ma sono totalmente sbagliati. Essere in grado di testare in modo indipendente i sub-parser rende molto, molto più facile ottenere l'intero parser giusto. Questo va di pari passo con la componibilità: costruire grandi parser mettendo insieme piccoli parser.
se la lingua è ambigua. Alcune lingue sono ambigue e alcuni strumenti non possono gestirle. Se ci sono più parsimoni validi, probabilmente voglio essere informato di ciò, possibilmente da un errore o da più risultati, invece di ottenere un solo parse e pensare che sia l'unico.
controlla i risultati di analisi. Quale output producono i parser: un albero di analisi concreto? I nodi sono strongmente digitati o digitati in modo stringato? Trovo molto utile avere un certo controllo su come viene costruito l'albero di analisi, mentre viene costruito; dovendo post-elaborare l'albero è spesso più doloroso e soggetto a errori, nella mia esperienza. Un esempio è un parser intero - dovrebbe restituire un intero o una stringa?
efficienza. Non ne so molto su questo, ma ci sono sicuramente differenze tra approcci diversi, specialmente quando c'è un sacco di backtracking.
segnalazione degli errori. Per lo meno, gli errori di analisi dovrebbero essere segnalabili con la posizione e le informazioni sulle regole correnti; una traccia può anche essere utile ma non ho visto alcuna soluzione decente a questo problema (anche se scommetto che ce ne sono alcuni).
espressività dello strumento di analisi. Mi fa saltare i cerchi per esprimere cose semplici come una sequenza di valori separati da virgole, senza virgola finale? Sono un grande fan di BNF, ma non essere in grado di estenderlo è frustrante, e può far sembrare le grammatiche molto più complicate, e quindi più difficili da mantenere, di quanto effettivamente ne abbiano bisogno. Essere in grado di catturare schemi e astratti su di essi non dovrebbe essere un lusso, ma un requisito.