What is all the fuss about how you can write DSLs in Lisp?
I found an interesting post on domain-specific languages and Lisp from June of 2007. It has this to say about designing a DSL:
"There are three approaches to designing programming language syntax. The first is to develop a good understanding of programming language grammars and parsers and then carefully construct a grammar that can be parsed by an LALR(1), or LL(k) parser. The second approach is to `wing it' and make up some ad-hoc syntax involving curly braces, semicolons, and other random punctuation. The third approach is to `punt' and use the parser at hand."
I like these categories. I find most folks do #2 with no tooling support or #3 using XML. MGrammar in Oslo is about making #1 easier than #2 and providing the tooling support, e.g. language-specific Intellisense services.
The real topic of the thread, however, is how to do a DSL in Lisp. The questioner would like to implement the following syntax:
trade 100 shares(x) when (time < 20:00) and timingisright()
I find this syntax to be reasonable for an event and it wouldn't be hard to imagine a system with a bunch of rules expressed this way and I could imagine a developer and a business person working together on such a system to ensure things were expressed properly. I don't think I could imagine the business person keeping up as well with syntax expressed as the answerer suggests, however:
(when (and (< time 20:00)
(timing-is-right))
(trade (make-shares 100 x)))
IMO, that's not a DSL -- that's just a set of function calls in an existing language.
Chris Sells
,
Monday, January 05, 2009 8:20 AM
You are blinded by your imperative mindset. This is not necessarily a set of function calls. Lisp removes the distinction of code and data; it provides a multitude of ways of processing that data, all of which can be combined.
It could be code.
Or, It could be quoted data, which could later be "EVAL"uated as code or could simply be processed as data or could later be transformed into code.
Or, It could be macro-expanded, which could be transformed into code or data.
Wesner Moise,
Monday, January 05, 2009 12:48 PM
Primary goal of DSL is enable simpler notation of execution steps specific for given domain compare to general purpose language. It therefore depends on domain constrains and target user skill set how DSL will look like. What parser, resource data and tooling is available is only secondary important.
I fully agree with Martin Fowler’s “Business Readable DSL article” (see http://martinfowler.com/bliki/BusinessReadableDSL.html) content: “With a business-readable DSL, programmers write the code but they show that code frequently to business people who can understand what it means. These customers can then make changes, maybe draft some code, but it's the programmers who make it solid and do the debugging and testing.”
Is well possible the end users will understand and use Lisp like notation. Equal is true with original syntax definition. However original syntax (i.g. trade 100 shares(x) when (time < 20:00) and timingisright()) seem to me is much closer to business user mindset due much closer relation to “Excell’s” VB office scripting environment.
I do not doubt Oslo with “MGrammar” will make it possible to define both versions of DSL. But this is not only alternative here. It just happened in my work we are in the middle of designing similar purpose DSL type for trading domain space with help of ANTLR and C#. At this point I do not feel the MGrammar will get any advantage against ANTLR for this particular case. The DSL vocabulary and syntax in our case is relatively limited, what is difficult is correct behavior and integration with rest of trading system. And there is no help with parser.
At this moment I kind of doubt MGrammer and Oslo is such big game changer here with 10x better of “everything”. At least not from strict DSL “enabler” point of view.
Regards,
Libor
Libor,
Monday, January 05, 2009 3:19 PM
@Libor,
>> At this moment I kind of doubt MGrammer and Oslo is such big game changer here with 10x better of “everything”. At least not from strict DSL “enabler” point of view.
Maybe. But the bigger question is the one asked by James Clark is his recent analysis of MGrammar @ http://blog.jclark.com/2008/11/mgrammar.html
>> "But if your platform provides tools that make it really easy to design new syntaxes, how do you avoid ending up in situation where every application has it's own private DSL? It doesn't help users if they have to learn a new syntax for every application. Certainly when I think about interchanging data on the Web, the fewer formats the better; I definitely don't want every application to be using its own completely custom syntax."
My own thoughts are three fold:
1) Hackers are /always/ going to hack, regardless of whether tools exist to make their hacks that much easier.
2) If they're going to hack anyway, giving them tools that encourage creating DSL's that are easily grok'd by the common man is a /very good thing/. The fact that it may require people to learn a new syntax should only be a concern if 1) The syntax is /drastically/ different than what's considered the norm, and 2) The language needs to be understood by a large group of developers who might be unfamiliar with the chosen syntax/coding style.
3) Both Lisp and XML enable the ability to create DSL's with ease. In both cases, a basic set of syntactic guidelines MUST be followed, yet rarely have I /ever/ heard someone speak of either syntax as a "joy to work with." The fact that I might know XSLT like the back of my hand doesn't mean I immediately understand /every/ DSL based on the XML syntax in the same way understanding Common Lisp doesn't mean I understand Scheme as well. In this regard, it's not so much the syntax itself that makes a language easier or harder to grok and instead the logic used in creating the DSL /regardless/ of the syntax.
In the above regard, and with /all/ due respect to James Clark, the "completely custom syntax" argument is a bit of red herring. The primary purpose and role of a DSL is to allow those using the DSL to be more productive with a specific task. If that's accomplished, then whether I use angle brackets instead of curly brackets, or periods instead of pipes is of little to no concern.
M. David Peterson,
Tuesday, January 06, 2009 2:01 PM
Cool!
Anton,
Wednesday, June 03, 2009 4:03 PM
Cool!
Anton,
Wednesday, June 03, 2009 4:08 PM
 Reply
to this news
Marquee de Sells
|