Hi, there are numerous examples on how to implement a DSL, but I haven't been able to figure out how to "design" one. I mean I have a pretty good idea of the problem domain, I've coded it over and over again until I got it right. Now I'd like to express that part as a DSL instead of "hard coding" it as before so I can be more prepared if I need to change or amend it. Ideally I'd only have to change the interpreter, right? And that I find to be the really tricky part, how do I *design* a DSL? Günther
Günther Schmidt wrote:
And that I find to be the really tricky part, how do I *design* a DSL?
My favorite approach is something like as described in these: http://lukepalmer.wordpress.com/2008/07/18/semantic-design/ http://conal.net/papers/type-class-morphisms/ It takes a little bit of time to come up with great abstractions, but when you finally do it's an amazing feeling. - Jake
On 2 okt 2009, at 20:37, Jake McArthur wrote:
Günther Schmidt wrote:
And that I find to be the really tricky part, how do I *design* a DSL?
I once wrote a tutorial on this subject in which I explain that designing a DSL is not so much different from an ordinary programming language; the only difference is that you do not have to think about type systems and abstraction mechanisms. The tutorial can be found in: @inproceedings{SwieAzSar98Braga, Author = {Swierstra, S. Doaitse and Azero~Alcocer, Pablo R. and Saraiva, Jo{\~a}o A.}, Booktitle = {Advanced Functional Programming, Third International School, AFP'98}, Date-Added = {2008-07-15 17:22:15 +0200}, Date-Modified = {2009-01-16 17:35:05 +0100}, Editor = {Swierstra, S. D. and Henriques, Pedro and Oliveira, Jos \'{e}}, Pages = {150-206}, Publisher = {Springer-Verlag}, Series = {LNCS}, Title = {Designing and Implementing Combinator Languages}, Volume = {1608}, Year = {1999}} It basically describes the origins of the Utrecht Attribute Grammar System, uuagc, available from hackage; the basic message is that when you implement a language you use compiler construction tools! An example of this can be found in a paper Olaf Chitil and I recently published in the JFP: @article{CambridgeJournals:2837460, Author = {SWIERSTRA, S. DOAITSE and CHITIL, OLAF}, Date-Added = {2009-02-13 10:17:23 +0100}, Date-Modified = {2009-02-13 10:17:23 +0100}, Doi = {10.1017/S0956796808006990}, Eprint = {http://journals.cambridge.org/article_S0956796808006990}, Journal = {Journal of Functional Programming}, Number = {01}, Pages = {1-16}, Title = {Linear, bounded, functional pretty-printing}, Url = {http://journals.cambridge.org/action/displayAbstract?fromPage=online&aid=2837460&fulltextType=RC&fileId=S0956796808006990 }, Volume = {19}, Year = {2009}, Abstract = { ABSTRACT We present two implementations of Oppen's pretty-printing algorithm in Haskell that meet the efficiency of Oppen's imperative solution but have a simpler and a clear structure. We start with an implementation that uses lazy evaluation to simulate two co-operating processes. Then we present an implementation that uses higher-order functions for delimited continuations to simulate co- routines with explicit scheduling. }, Bdsk-Url-1 = {http://journals.cambridge.org/action/displayAbstract?fromPage=online&aid=2837460&fulltextType=RC&fileId=S0956796808006990 }, Bdsk-Url-2 = {http://dx.doi.org/10.1017/S0956796808006990}} This paper describes two implementation of a functional pretty printing, finally solving the problem how to do so with limited alook- ahead, as in Oppen's orginal paper. One of the solutions was created using an attribute grammar way of thinking and the attribute grammar can be found at the end of the technical report, and I hope that this example convinces you of the elegance of this approach: @techreport{PPTr2004, Author = {Swierstra, S.D.}, Date-Added = {2009-01-04 17:21:54 +0100}, Date-Modified = {2009-01-04 17:21:54 +0100}, Institution = {Inst. of Information and Comp. Science, Utrecht Univ.}, Note = {submitted for publication}, Number = {UU-CS-2004-025a}, Pubcat = {techreport}, Title = {Linear, Online, Functional Pretty printing (extended and corrected version)}, Urlpdf = {{http://archive.cs.uu.nl/pub/RUU/CS/techreps/CS-2004/2004-025a.pdf }}, Year = 2004} In a more abstract setting your question is also "How do I design a library", "How do I design a consistent theory", and "How do I model something". These questions are harder to answer ;-} Doaitse Swierstra
Günther Schmidt wrote:
there are numerous examples on how to implement a DSL, but I haven't been able to figure out how to "design" one.
I mean I have a pretty good idea of the problem domain, I've coded it over and over again until I got it right. Now I'd like to express that part as a DSL instead of "hard coding" it as before so I can be more prepared if I need to change or amend it. Ideally I'd only have to change the interpreter, right?
And that I find to be the really tricky part, how do I *design* a DSL?
Since every well-designed DSL is, by definition, a unique experience, it's hard to answer that question in general. I think that designing DSLs in Haskell is best learned from the following classic papers John Hughes. The Design of a Pretty-printing Library. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.8777 Philip Wadler. A prettier printer. http://homepages.inf.ed.ac.uk/wadler/topics/ language-design.html#prettier Richard Bird. A program to solve Sudoku Slides: http://icfp06.cs.uchicago.edu/bird-talk.pdf Paper: http://cs.tufts.decenturl.com/richard-bird-sudoku Simon Peyton Jones, Jean-Marc Eber, Julian Seward. Composing contracts: an adventure in financial engineering. http://research.microsoft.decenturl.com/composing-contracts and Hudak's book Paul Hudak. The Haskell School of Expression. http://www.haskell.org/soe/ The main principle is probably best summarized as: think long and hard to make it as simple and beautiful as possible. Regards, apfelmus -- http://apfelmus.nfshost.com
participants (4)
-
Günther Schmidt -
Heinrich Apfelmus -
Jake McArthur -
S. Doaitse Swierstra