Come e quando dovrei progettare un parser di linguaggio mark-up semplice? [chiuso]

Per la tua circostanza specifica, vorrei solo andare avanti e provare a scrivere un parser se hai il tempo libero. Ti consiglio di iniziare con i parser basati su XML, in quanto questi sono i più semplici (poiché l'albero della sintassi è già stato scritto per te nel file XML).

Per la domanda più generale su quando è valido scrivere un parser, direi che il seguente deve essere vero:

1. Gli input del parser cambiano spesso e impiegherebbero più tempo per apportare le modifiche agli output parser codificati in modo hard rispetto a quelli che modificerebbero gli input del parser
2. Il parser affronta un dominio problematico limitato e ben compreso, che cambia sia raramente che segnala modifiche
3. Il tempo totale necessario per scrivere gli equivalenti codificati su tutti gli output parser di tutti i suoi file di input è maggiore della quantità di tempo necessaria per scrivere lo stesso parser
4. Il linguaggio trattato dal parser è più semplice o più conveniente per il suo utente finale rispetto alla lingua che l'equivalente output codificato verrà scritto in

Questo può sembrare un po 'opinabile e complesso, ma il mio ragionamento è essenzialmente che un parser richiede molto tempo per scrivere bene. Affinchè il parser paghi il suo debito (in termini di tempo impiegato per scriverlo), deve occuparsi di un dominio problematico in cui l'alternativa al parser sarebbe scrivere un sacco di codice per gestire ogni potenziale input per il parser. Quindi analizziamo le credenze precedenti con l'esempio di parser HTML e HTML:

1. Le pagine HTML effettivamente cambiano spesso e ci vorrebbe più tempo per cambiare l'albero visivo come scritto in C ++ piuttosto che modificare l'albero visivo come scritto in HTML. Per cambiare la posizione di un div in HTML, o per cambiare il suo stile, si può semplicemente tagliare e incollare il div esistente da qualche altra parte nell'albero, e si può semplicemente applicare una nuova classe css. Fare l'equivalente in C ++ sarebbe molto più difficile, perché non sarebbe neanche lontanamente facile come tagliare e incollare lo stesso codice in qualche altra parte del file C ++.
2. Le specifiche HTML sono finite e ben comprese. È noto quando le specifiche cambieranno, perché il W3C convoca molte riunioni prima di ogni modifica. Ciò significa che gli autori di parser HTML sanno quando sta per cambiare, quindi possono essere preparati alle modifiche e non sprecare grandi quantità di tempo anticipando le modifiche nel dominio problematico. Il fatto che il dominio del problema sia ben compreso e finito fornisce anche ai parser-writer una buona base per dire che il loro parser è completo, cioè un parser HTML è completo quando gestisce tutti gli elementi HTML noti che leggerà. Immagina di provare a scrivere un parser per qualcosa che cambia costantemente e che è vagamente definito; come faresti a sapere che il tuo parser è stato completato?
3. Analogamente al punto 1, immagina di provare a scrivere una pagina web come un insieme di istruzioni C ++. Venire con un modo coerente di gestire i layout degli elementi sullo schermo richiederebbe più tempo rispetto alla scrittura di un semplice div! Inoltre, dato che ci sono ~ 2.51 miliardi di pagine web, immagina la perdita di tempo di scrivere ogni pagina web nei propri file C ++, con i suoi stessi framework. Se un parser salva enormi quantità di tempo rispetto alla scelta alternativa, e il parser sarà usato spesso, allora è un buon segno che il parser potrebbe essere un positivo netto.
4. Ancora una volta, se le pagine web fossero scritte in C ++, il gruppo di persone in grado di scriverle sarebbe gravemente ridotto. Non per essere snob, ma penso che possiamo essere tutti d'accordo sul C ++, con le sue numerose e complesse insidie e segfaults, è molto più difficile dell'HTML. Se solo gli inveterati sviluppatori C ++ potessero scrivere pagine Web, allora azzarderei un'ipotesi che sicuramente non avremmo ~ 2.51 miliardi di pagine web.

Come un po 'di aneddoti personali, la mia azienda ha scritto un parser per un client che prende XML e usa quell'XML per leggere e scrivere dati da e verso stored procedure SQL in fogli di calcolo. Il client è in grado di capire qualcosa del tipo:

<Workbook name="SomeWorkbook">
    <Sheet name="SomeWorksheet">
        <DataCell range="A1" name="employee" input="SPGetEmployees" />
        <DataCell range="A2" name="salary" input="SPGetEmployees" />
        <DataCell range="B3" name="total" input="SPGetEmployees" />
        <DataCell range="B4" name"isApproved" output="SPApproveWorksheet" />
    </Sheet>
    <DataSources>
        <DataSource direction="input" type="SP" database="someDatabase" name="SPGetEmployees">
            <Parameters>
                <Parameter name="financialYear" type="DateTime" isDataCell="false" />
            </Parameters>
        </DataSource>
        <DataSource direction="output" type="SP" database="someDatabase" name="SPApproveWorksheet">
            <Parameters>
                <Parameter name="isApproved" type="Bit" isDataCell="true" />
            </Parameters>
        </DataSource>
    </DataSources>
</Workbook>

perché sembra tutto loro familiare nel loro ruolo di lavoro (amministratori di sistemi semi-tecnici), ma il cliente sicuramente non capirebbe il codice C # che altrimenti genererebbe questa cartella di lavoro. Anche le loro fonti di dati per i loro fogli di lavoro cambiano spesso, ed è più veloce cambiare un codice XML piuttosto che cambiare un sacco di codice C #. Il dominio del problema è anche ben compreso, perché stiamo solo leggendo e scrivendo da alcune fonti di dati ben comprese ad alcuni output ben noti (file Excel), così possiamo scrivere un linguaggio basato su XML che fornisce tutte le esigenze del cliente e non deve essere cambiato molto spesso.

Ti lascerò con questa ultima precauzione da xkcd sull'argomento delle ottimizzazioni come i parser: link