Ayende @ Rahien

Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 5,969 | Comments: 44,490

filter by tags archive

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

Reshef Mann

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.

Ayende Rahien

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.

Steve

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

Steve

Is your DSL going to be built with Boo ?

Det. Alonso Alagré

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?

Ayende Rahien

Steve,

Thanks for the ideas.

Yes, the DSL is based on Boo

Ayende Rahien

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.

Det. Alonso Alagré

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 ;) !

ActiveEngine Sensei

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.

Søren Skovsbøll

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

(

    ? "What's the brand of this vacuum cleaner?" list ("Siemens", "Miele", "Other")

    ? "When did you buy it?" integer (1970 - 2007)

)

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

Apache Camel

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

JKM
JKM

I have been thinking about doing a DSL for the bible. Not sure how I would go about it exactly.

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. Production postmortem (5):
    29 Jul 2015 - The evil licensing code
  2. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
  3. API Design (7):
    20 Jul 2015 - We’ll let the users sort it out
  4. What is new in RavenDB 3.5 (3):
    15 Jul 2015 - Exploring data in the dark
  5. The RavenDB Comic Strip (3):
    28 May 2015 - Part III – High availability & sleeping soundly
View all series

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats