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