<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <style>  </style> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1><pre>In my case, I look at both the simulation collection and the inference collections that I’ve developed in PLT Scheme to be examples of domain-specific languages (DSLs) – an internal DSL, to use Martin Fowler’s terminology.  Both implement a domain-specific language on top of PLT Scheme – a simulation language in the first case and a rule-based language in the second.  These are more problem-solving domain oriented than application domain oriented.  I would say the real power is in the underlying PLT Scheme implementation itself.  That is, I can provide a veneer of domain-specific syntax and functionality and rely on the underlying language implementation to provide the depth needed to solve real problems within these domains.  Maybe a term like domain-specific language extension is more appropriate here.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>The advantage of this approach of embedding a DSL in PLT Scheme is, at least to me, pretty obvious.  I get the domain-specific problem solving abstractions that can be applied to solve specific problem instances.  And, I can use the richness of the underlying implementation to the extent desired to round out the problem solving application – anywhere from simply printing (or plotting) the results to a full-blown graphical application.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>The disadvantage in this case is probably just as obvious.  You have to know the underlying language – PLT Scheme – to use the DSL.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>I rarely write a simulation or rule-based system for its own sake.  They are generally a part of a much larger system.  I also often develop knowledge-based simulations thatuse elements from both problem-solving domains.  This is not a problem when the separate DSLs are embedded in the same language framework.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Doug<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>On 6/7/07, Grant Rettke <<a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme">grettke at acm.org</a>> wrote:<o:p></o:p></pre><pre>> What is all the fuss about how you can write DSLs in Lisp?<o:p></o:p></pre><pre>><o:p> </o:p></pre><pre>> Everyone from thought-leaders to blog-posters to grandma's are talking<o:p></o:p></pre><pre>> about how Lisp is so great for DSLs.<o:p></o:p></pre><pre>><o:p> </o:p></pre><pre>> About what are these people talking about? Because no one of said<o:p></o:p></pre><pre>> people actually elaborate on any of this, of course, which leads me to<o:p></o:p></pre><pre>> question their claims.<o:p></o:p></pre> <o:p> </o:p> </div> </body> </html>