Non è possibile che un DSL sia semplice come un'API e pertanto non è necessario un parser? O sto fraintendendo cosa sia un linguaggio specifico di un dominio? Ho pensato che si riferisse a qualsiasi insieme organizzato di regole per risolvere un particolare problema del dominio. Un'API sembrerebbe adattarsi a quella definizione, giusto?Perché gli strumenti di analisi sono necessari per i DSL?
È possibile incorporare una DSL in un linguaggio di programmazione più generale. Questa è spesso una buona soluzione. (Si potrebbe dire che questo DSL prende la forma di una particolare API.)
È inoltre possibile creare una lingua separata, con un proprio interprete, per rappresentare i concetti del proprio dominio. Questo tende ad essere un'impresa più grande e spesso non è necessario.
Avresti ancora solo la semantica della lingua dell'host.
E.g .: la programmazione funzionale in un linguaggio imperativo non funziona. Quindi hai un DSL funzionale aggiunto a questa lingua imperativa ...
Ah. Quindi un DSL ha lo scopo di superare i limiti semantici di un particolare linguaggio estendendolo? Ed è qui che serve il parser - il parser 'interpreta' le tue estensioni semantiche personalizzate - è corretto? –
Questa è la mia interpretazione di DSL, anche se ho solo esperienza con DSL extern. Say, SQL;) – Leonidas
Stai confondendo il concetto con l'implementazione. Un linguaggio specifico del dominio è qualsiasi rappresentazione di un'idea considerata "vicina" al dominio del problema, piuttosto che essere un linguaggio generale per la descrizione della risoluzione dei problemi in generale.
Sì, un DSL potrebbe essere implementato come un'API, che ha fornito funzioni che si riferivano a concetti particolari nel dominio del problema, ma un DSL è ugualmente valido quando rappresentato come un file di testo.
Il programmatore pragmatico: da Journeyman a Master contiene una buona descrizione dei DSL e le circostanze in cui sono utili, con esempi. Altamente raccomandato.
Sì, assolutamente - a semplice API funzionerà correttamente come DSL se la lingua host dispone di flessibilità sufficiente per supportarlo.
Ruby è un linguaggio molto buono per questo, in particolare dati i parents opzionali e altre flessibilità.
Rails è spesso indicato come un DSL per la scrittura di database-driven web applicazioni.
Rake è un sistema di compilazione con DSL per makefile di scrittura (più intelligente) .
mia OOFILE è un quadro si può considerare come un DSL per la scrittura di applicazioni di database in C++ - è stato ispirato da dBase e fa un uso molto pesante di C++ overloading degli operatori, oggetti locali e idiomi flusso.
Forth è classicamente un linguaggio che offusca la linea tra DSL e API poiché un programma Forth consiste in poco più di una serie di parole separate dallo spazio. Probabilmente l'esempio più impressionante di un Forth DSL è Abundance - L'abbondanza è un linguaggio di programmazione aziendale basato su Forth, scritto in BBL Forth. BBL è un compilatore DOS FORTH a 32 bit. Distribuito come è. Vedi gli avvertimenti. Questo non è per i deboli di cuore. Potrebbe interessare principalmente qualcuno che sviluppa software per il terzo mondo in cui è necessaria un'esecuzione rapida su vecchi computer klunker XT e AT. Puoi scrivere alcuni programmi di immissione dati molto sofisticati che gireranno intorno ai moderni programmi di inserimento dati.
E, naturalmente, un DSL grafico non richiederebbe affatto l'analisi.
Questa è una risposta davvero fuorviante. Qualcosa deve "accettare i frammenti DSL" dal programmatore DSL e verificare che cosa è stato inserito sia valido. Che si tratti di un generatore di parser tradizionale per linguaggi basati su stringhe o di un'interfaccia utente grafica ad hoc che accetta caselle e frecce che collegano le caselle o un'interfaccia utente generata automaticamente da una grammatica del grafico, devi ancora avere questo macchinario. E il macchinario per una DSL testuale è attualmente molto più facile da mettere insieme di uno per una langauge grafica. Puoi dire che un maiale è un cane, ma è ancora un maiale. –
@Ira: Penso che dovresti dare un'occhiata al DSL Toolkit nell'SDK di Visual Studio. Non c'è parsing. Non c'è accettazione di frammenti. L'interfaccia utente accetta i gesti della GUI come trascinamento e rilascio, insieme ai comandi di menu o tastiera e crea una rappresentazione in memoria dell'istanza DSL. È _building_, non _parsing_. –
Se ci sono gesti illegali, è "parsing". Anche i parser di stringa "costruiscono" strutture di dati nella memoria, e non riesco a vedere che ciò faccia differenza nella discussione su cosa sia l'analisi. Potresti dire "ma non ho dovuto scrivere il parser". Ok, potrei essere d'accordo, ma di nuovo la distinzione tra questo e Bison (che non devi scrivere) non è molto; da qualche parte, qualcuno (tu?) deve dire che cos'è una struttura legale, e qualcosa deve controllare che ciò che stai "gesticolando" produce una tale struttura legale. Hai * un * parser e sta analizzando. –
Il difetto fondamentale delle API come "DSL" è che in un linguaggio esistono ordini di sintassi e semantica implicita. Quando si utilizza un'API, è possibile scrivere qualsiasi sequenza di chiamate API che vengono compilate, ma le seqeu arbitrarie non sono legali. Il valore in un * langauge * è che definisce quali sequenze sono legali e un buon "parser" (ad esempio, quello che analizza e controlla la semantica) rigetterà le sequenze prive di senso senza che tu debba eseguirlo. –
Sono d'accordo. Ci sono certamente numerosi motivi per scrivere un DSL esterno. Un semplice esempio è: se il DSL è destinato agli utenti non fidati che scrivono programmi, allora non li vuoi scrivere in un vecchio linguaggio di programmazione (come la lingua in cui il tuo DSL potrebbe essere incorporato). Ci sono pro e contro per entrambi gli approcci. La mia opinione è: è più facile per gli ordini di grandezza scrivere un DSL incorporato in una buona lingua ospite. Pertanto, nella misura in cui è ragionevole farlo, farlo. Ma se un DSL incorporato è insufficiente, allora è necessario scrivere un DSL esterno che sia sufficiente. – yfeldblum
Ecco un esempio di documentazione DSL http://www.robusthaven.com/blog/parsing-expression-grammar/npeg-dsl-documentation che è possibile utilizzare inline in C# o per esportare il parser utilizzando il linguaggio workbench http://www.robusthaven.com/blog/parsing-expression-grammar/npeg-language-workbench –