+972 52-548-6969
Looking for a DSL idea
I need to start writing the second part of the book soon. This one is supposed to take a DSL implementation through all the interesting stages that I would like to cover. However, I am not sure yet what the subject of the DSL will be.
I need something that has enough scope to last for about a hundred pages, complex enough to expose usual problem when writing DSL and not tied to a specific domain so strongly that it would be hard to outsiders to grasp.
I am also interested in knowing what kinds of patterns and problems you would like me to cover.
My current line of thinking is to build several DSL around the backend of an online store. That domain should be fairly familiar to all, and it is rich enough to offer a lot of things to discuss. It is also a good place to discuss several types of DSL.
I was thinking of the following DSL:
- Message routing / dispatch DSL
- Order processing DSL
- Then we will extend that to be a generic rule engine DSL
- Perhaps creating a testing DSL for those DSL or for the domain itself
The main problem that I have now is that building those DSL is very simple, I don't think that it would be enough to cover everything the we need to build DSL. In that light, I am looking for either more ideas or challenges on the use of the above mentioned DSL.
Comments
I think that DSL debugging is a very important issue that needs to be addressed.
For the subject, I think that my domain can be interesting - telephony. It has business plans, billing user account, interacting with telephony servers etc.
Reshef,
I am going to address debugging, certainly.
Although that may be a bit tricky, given that we purposefully do not want to look like a programming language.
The problem with the domain is that it has to be complex enough to be useful and familiar enough that I wouldn't need to explain what is going on there.
You mention orders - I'd like to see how flexible an ordering system would be using DSL where you have significant product line differences.
ie. configuration of products that different customers have negotiated different costs.
ie. 3rd party items where you produce maybe 2 of the 3 items, but one of them is actually manufactured at a different company.
ie. backorders - determining when an order is complete for invoicing
Is your DSL going to be built with Boo ?
Maybe a DSL to create regular expression? That may end up a little limitating, but for the 90% of the common needs could be a more human readable way of creating regular expressions.
Ayende? What you say?
Steve,
Thanks for the ideas.
Yes, the DSL is based on Boo
Alonso,
I don't think so, you can check a few of the fluent interfaces for regex, they seem to do most of the work just fine.
Yeah Ayende, just like code generators, right? I think the point is the same: having a tool generating an underlying syntax via a gui interface or some wizards versus a having a language.
On top of that you could push supported features as you like, to have it complex as you like ("...it has to be complex enough...") and regular expressions is something quite known... not deeply known maybe, but for who runs with scissors it is surely something at least known ("...be useful and familiar enough...").
Anyway, as you like ;) !
Auto manufacturing / auto dealer would be a good subject, as you can have different lines of products with different sub-products and rules that govern what can be included in a final car package. Supply chain can be incorporated as well for part and automobile locations, etc.
Plus, you have the opportunity to represent current CAFE standards as well as the mandate for a flexible rules engine that supports new CAFE standards, ala what's been passed recently in the US.
Ayende,
one problem domain that is general and still close to many customers' world is questionnaires. I have created a DSL for that purpose, although using Gold Parser and not Boo.
Questionnaires tend to (like most other things) start out pretty simple, but soon the customer wants to be able to define for instance questions that yield other questions, or to define new types of possible answers.
Here's an example of a questionnaire definition:
Section "Appliances"
? "How many vacuum cleaners have you got?" integer (0-10)
for each answer
(
)
The downside of my suggestion (related to your book) is that it's an example of a 100% declarative DSL, where as Boo gives the power to mix declarative and imperative DSLs, and is strongest at imperative ones.
I look forward to reading your book,
Søren
a few months back when i had some down time, i played around with implementing porting parts of this to .net
http://activemq.apache.org/camel/
l0t3k
I have been thinking about doing a DSL for the bible. Not sure how I would go about it exactly.
Comment preview