Summary
The renewed popularity of functional languages opens up new possibilities for defining domain-specific languages. In a recent article, Debasish Ghosh describes the use of parser combinators in Scala as a way to implement a DSL that can work with any Java code.
Advertisement
Domain-specific languages are a popular technique for devising easy-to-understand programming constructs for a domain. Code generation and the metaobject protocol of dynamic languages, such as Ruby, are the most prevalent ways to build DSLs today.
The increased popularity of functional languages opens up new, possibly more effective, ways to devise a DSL, however. In such languages, functions can take other functions as argument values, and a function can also return another function as a result of a computation. In addition, it is also possible to use functions as operators in a functional language. When a function is used as an infix operator, standing between two operands, the function is called a combinator.
In a recent blog post, External DSLs made easy with Scala Parser Combinators, Debasish Ghosh describes how to take advantage of such combinators to define parsers for a DSL. The technique is not new, but its relative ease in Scala enables anyone to use this technique on the JVM.
Ghosh writes in his article that such use of Scala is an excellent example of employing aspects of various languages in a project in order take advantage of a language's strengths:
The basic idea of polyglotism is to harness the power of multiple languages in their respective strength areas. Languages like Scala, despite being statically typed offer lots of flexibilities and conciseness. Offering the strong features of both OO and functional paradigms, Scala shines in providing parser combinator libraries straight out of the box.
Ghosh defines parser combinators as a sort of higher-order function:
A parser combinator is a higher order function that accepts a parser and applies transformation functions to generate more complex parsers. Hence parser combinators are easily implemented in languages that have strong support for functional programming.
In the article, Ghosh explains that his project used XML as a domain language. Replacing the XML DSL with a Scala parser-generator resulted in simpler code, and had the following advantages:
Easy to implement
As concise as your EBNF productions
Algebraic data types to generate ASTs and
Powerful pattern matching techniques to inspect them.
Add to them the fact that I can have the entire stack running on the JVM, with Java objects still running the show at the backend. This implies that I do not have to reimplement my current Java application. I can just plug in the DSL and have the parser cook up my Java objects at the AST level...
And the most interesting part is that, the methods above have almost a one-to-one correspondence to EBNF production rules, as I would write them in a natural language. All the heavy lifting of lexical analysis and parsing are taken care of by the Scala parser combinator library.
What do you think of the benefits functional languages bring to DSLs?
It's a very cool idea. Unfortunately I think it is also usually a very, very wrong idea. It seems to me that good library design plus a very few syntactic goodies in a general purpose language (closures, properties, etc.) give you 90% of the bang of DSLs with minimal mental impact.
There is a biblical story indicating that this sort of thing ends up in tears.
> I agree with Bjarne that true DSLs (with a new syntax) > should be an absolute last resort
yeah, sorta true.
but as with all things, "it depends". if you have people who can program then sure avoiding a DSL could be good. if, however, you really do need to support non-nerds, you should be able to do a DSL. also, if you are going to write your libraries in a crappy overly verbose painful language rather than something which allows for nice clean syntax, maybe go for a DSL? ;-)
or maybe "absolute last resort" is meant to imply "it depends" but it doesn't really sound like that to my ears.
"absolute last resort" does imply "it depends", but I'm more skeptical of supporting non-nerds with DSLs. Eventually someone wants a for loop and an if statement, and, once you cross that Rubicon, you might as well just use a general purpose language that doesn't suck.
An example that I have seen that makes me skeptical of DSLs are the rule-engines that exist out there to convince non-programmers that they can program "business logic" in some little DSL. They end up being an order of magnitude more complicated, with bizarre symbol management and insane control flow, than just sacking up and writing the code in an old fashion gp language.
How do you feel parser combinatiors compare to using a parsing DSL? The following example uses the PARSE function in REBOL, which itself uses a DSL to specify the grammar. I don't know if Scala has something similar.
display-action: func [blk] [print blk]
action=: [set action ['buy | 'sell] ] shares=: [set shares integer!] security=: [set company word! 'shares 'at | 'shares 'of set company word! 'at] limit=: [set limit-type ['max | 'min] set price money!] account=: ['for opt ['trading 'account] set account issue!] rules: [ some [ action= shares= security= limit= (display-action [company (pick ["income" "cost"] action = 'sell) price * shares]) ] account= (print ["Processing complete for account" mold account]) ]
input: [ buy 100 IBM shares at max $45.00 sell 40 Sun shares at min $24.50 buy 25 shares of CISCO at max $56 for trading account #A1234 ]
parse input rules
Produces:
IBM cost $4500.00 Sun income $980.00 CISCO cost $1400.00 Processing complete for account #A1234 == true
> An example that I have seen that makes me skeptical of > DSLs are the rule-engines that exist out there to convince > non-programmers that they can program "business logic" in > some little DSL.
hm. so pragmatically the reason for the DSL in the first place is to avoid having to teach people how to program. especially because if you told the hypothetical audience for this mental experiment that they had to "program" then they might just not even try your stuff.
but then over time they start to ask for things which are basically programming; loops, conditionals, variables, whatever.
dogged.
on the other hand, tangentially related, i think of things like Make or Haskell's monads where you can take something to the extreme (declarative, purity) and if you are smart enough and dogged enough, come through the other side with something really cool (persistant pure data structures, for example). so you could have a business DSL that was purely declarative perhaps and avoid the looping etc. but you'd have to (a) have a really good design for the DSL's implementation of declarativeness and (b) you'd have to teach everybody how to think that way. which is perhaps more difficult to get across; it is almost like teaching a new math to somebody. so maybe indeed the layman's brain works better with imperative procedural recipie approaches. but then you get back into the whole issue of side effects coming back to bite you and them in the ass with confusing bugs.
we can't win? there will never be a "star trek" programming language that Just Works?
I'm interested in creating a DSL for equity exotic product structurers. The requirements are: - based on a set of objects that are produced by a user-interface designer, we want to define payoffs and life-cycle in a language a structurer can write easily - the script produced should "compile" to: -- XML that can be consumed by a document generator -- a serialized format used by a life-cycle system -- a generic pricing code in another language
Previous Topic
