Domain Specific Languages

Open seats for the DSL course

Ayende Rahien — Sat, 10 May 2008 17:55:12 GMT

There are still open seats for the DSL course in Austin, next week (19th - 20th May).

You can register here: http://ayende.eventbrite.com/

Course: Building Domain Specific Languages in Boo

Ayende Rahien — Tue, 06 May 2008 01:33:54 GMT

You can register here for a two days course in building DSL with Boo.

It is going to take place two weeks from today, in Austin. (19 - 20 May)

I know that this is short notice, but it wasn't something that was planned well in advance. It came out of the ALT.Net conference.

Topics:

Creating Domain Specific Languages
The Boo Language
Flexible compiler and malleable language
Creating applications with embedded DSL
Management, tracing and debugging
Tooling support
Testing and maintainability concerns

There are ten seats open for that.

I hope we would have fun.

I would also like to thank Jeffrey Palermo and Headspring for hosting the course.

DSL Article on InfoQ

Ayende Rahien — Mon, 21 Apr 2008 16:10:20 GMT

My DSL article has been published on InfoQ!

You can get it here

The quote generation DSL

Ayende Rahien — Sun, 30 Mar 2008 22:51:21 GMT

I am doing some work on the DSL book right now, and I run into this example, which is simple too delicious not to post about.

Assume that you have the following UI, which you use to let a salesperson generate a quote for your system.

This is much more than just a UI issue, to be clear. You have fully fledged logic system here. Calculating the total cost is the easy part, first you have to understand what you need.

Let us define a set of rules for the application, is will be clearer when we have the list in front of us:

The Salary module requires a machine per every 150 users.
The Taxes module requires a machine per 50 users.
The Vacations module requires the Scheduling Work module.
The Vacations module requires the External Connections module.
The Pension Plans module requires the External Connections module.
The Pension Plans module must be on the same machine as the Health Insurance module.
The Health Insurance module requires the External Connections module.
The Recruiting module requires a connection to the internet, and therefore requires a fire wall of the recommended list.
The Employee Monitoring module requires the CompMonitor component

Of course, this fictitious sample is still too simple, we can probably sit down and come up with fifty or so more rules that we need to handle. Just handling the second level dependencies (External Connections, CompMonitor, etc) would be a big task, for example.

Assume that you have not a single such system, but 50 of them. I know of a company that spent 10 years and has 100,000 lines of C++ code (that implements a poorly performing Lisp machine, of course) to solve this issue.

My solution?

specification @vacations:
	requires @scheduling_work
	requires @external_connections
	
specification @salary:
	users_per_machine 150
	
specification @taxes:
	users_per_machine 50

specification @pension:
	same_machine_as @health_insurance

Why do we need a DSL for this? Isn’t this a good candidate for data storage system? It seems to me that we could have expressed the same ideas with XML (or a database, etc) just as easily. Here is the same concept, now express in XML.

<specification name="vacation">
	<requires name="scheduling_work"/>
	<requires name="external_connections"/>
</specification>

<specification name="salary">
	<users_per_machine value="150"/>
</specification>

<specification name="taxes">
	<users_per_machine value="50"/>
</specification>

<specification name="pension">
	<same_machine_as name="health_insurance"/>
</specification>

That is a one to one translation of the two, why do I need a DSL here?

Personally, I think that the DSL syntax is nicer, and the amount of work to get from a DSL to the object model is very small compared to the work required to translate to the same object model from XML.

That is mostly a personal opinion, however. For pure declarative DSL, we are comparable with XML in almost all things. It gets interesting when we decide that we don’t want this purity. Let us add a new rule to the mix, shall we?

The Pension Plans module must be on the same machine as the Health Insurance module, if the user count is less than 500.
The Pension Plans module requires distributed messaging backend, if the user count is great than 500.

Trying to express that in XML can be a real pain. In fact, it means that we are trying to shove programming concepts into the XML, which is always a bad idea. We could try to put this logic in the quote generation engine, but that is complicating it with no good reason, tying it to the specific application that we are using, and in general making a mess.

Using our DSL (with no modification needed), we can write it:

specification @pension: 
	if information.UserCount < 500: 
		same_machine_as @health_insurance 
	else: 	
		requires @distributed_messaging_backend

As you can imagine, once you have run all the rules in the DSL, you are left with a very simple problem to solve, with all the parameters well known.

In fact, throughout the process, there isn't a single place of overwhelming complexity.

I like that.

New version of the book out!

Ayende Rahien — Fri, 14 Mar 2008 10:14:33 GMT

Chapters 5 - 7 are now available, covering a lot of the building of a DSL and integrating that into an application.

This version contains a lot of fixes from reviewers, but I intend to make some chapter shuffling which will put the hard core stuff toward the middle of the book, after we cover more interesting scenarios.

Building Domain Specific Languages with BOO

Building Domain Specific Languages in Boo: Available for early access

Ayende Rahien — Sun, 17 Feb 2008 21:15:51 GMT

Well, this is a big moment. My book is now available for as part of the Manning Early Access Program.

Chapter 1 to 4 are already there, but they are there in their nearly raw format. That means that they have not been edited yet, and I didn't put in the results from the review cycle that we did yet.

The book forum is here, I eagerly awaits the posts telling me how off base I am :-)

More seriously, I would appreciate any feedback that you have on the book, the topic, the code, etc.

Thanks,

~Ayende

Fun with DSL - Didja know the CLR allows it?

Ayende Rahien — Thu, 14 Feb 2008 14:34:20 GMT

I swear that I didn't mean to do it, but it just happened.

Refactoring for Separation Of Concerns: A real world example

Ayende Rahien — Thu, 14 Feb 2008 13:41:55 GMT

I just did a major refactoring to Rhino DSL, to add orthongality to the DslEngine. It was an interesting refactoring, and something that is worth talking about.

Let us take a look at the before image, first:

We have two classes that are involved in creating and managing DSL. Notice the FileFormat, CreateInput, GetMatchingUrlsIn and NotifyOnChange methods on the DslEngine? Or the GetFromCache, RemoveFromCache, SetInCache methods?

The firsts are related to the storage of the DSL scripts on disk and the second batch are related to caching, they have nothing to do with the actual work performed by the DslEngine. Those are completely different responsibilities and concerns. I didn't feel the pain of mixing the responsibilities until I had to create a class that wanted to change the storage mechanism of the scripts. Looking at it, the cache methods especially really want to move to another class. You can tell by their names.

Then I realized that I had to override a bunch of methods and correlate results between them, and I found myself thinking, "Who the hell wrote this nightmare?" *.

Changing the storage mechanism, something that I certainly wanted to support, has gotten fairly involved, and I couldn't see anyone figuring out all the knobs they had to turn without reading the source, carefully. This is a bad situation to be in.

Hence, refactoring.

What was involved in this was mostly moving code around. The technicalities of it where mostly these:

Ask R# to extract super class with the unrelated methods.
Ask R# to extract an interface from the new super class
Remove the inheritance association with the DslEngine
Add a property for the new interface type
Initialize the property to use a default implementation
Fix code that broke as a result (mostly involved adding the property name before the method).
Rename methods to match current location (Removing the "Cache" from the methods in the caching interface).

The result is this:

Now, changing the storage mechanism doesn't need to affect the DSL implementation. We have a more robust model, and a good example for the blog.

Of course, I just finished writing half a chapter about the old way of doing things... Time for a rewrite.

* I often think thoughts like this, the sad answer is often: "Me".

Debugging DSL

Ayende Rahien — Wed, 30 Jan 2008 22:08:41 GMT

Well, that is fairly easy, all you need it to press F11 :-)

Purely declarative DSL

Ayende Rahien — Wed, 30 Jan 2008 08:01:35 GMT

Let us assume that we need to build a quote generation program. This mean that we need to generate a quote out of the customer desires and the system requirements.

The customer's desires can be expressed in this UI:

The system requirements are:

The Salary module is specification is a machine per every 150 users.
The Taxes module requires a machine per 50 users.
The Vacations module requires the Scheduling Work module.
The Vacations module requires the External Connections module.
The Pension Plans module requires the External Connections module.
The Pension Plans module must be on the same machine as the Health Insurance module.
The Health Insurance module requires the External Connections module.
The Recruiting module requires a connection to the internet, and therefore requires a fire wall of the recommended list.
The Employee Monitoring module requires the CompMonitor component

The first DSL that I wrote for it looked like this:

if has( "Vacations" ):
	add "Scheduling"
	
number_of_machines["Salary"] = (user_count % 150) +1
number_of_machines["Taxes"] = (user_count % 50) +1

But this looked like a really bad idea, so I turned to a purely declarative approach, like this one:

specification @vacations:
	requires @scheduling_work
	requires @external_connections
	
specification @salary:
	users_per_machine 150
	
specification @taxes:
	users_per_machine 50

specification @pension:
	same_machine_as @health_insurance

The problem with this approach is that I wonder, is this really something that you need a DSL for? You can do the same using XML very easily.

The advantage of a DSL is that we can put logic in it, so we can also do something like:

specification @pension: 
	if user_count < 500:
		same_machine_as @health_insurance
	else:
		requires @distributed_messaging_backend
		requires @health_insurance

Which would be much harder to express in XML.

Of course, then we are not in the purely declarative DSL anymore.

Thoughts?