A Look at DSLs

If you have never seen or written any XML thus far, consider yourself very lucky.

XML started out as a very friendly and sane way to represent data so that it would be human readable and machine readable at the same time. Of course, this sounded pretty darn great, until people began building incredibly large systems (and, arguably, overengineered systems) based on XML. This site is a welcoming place for programmers of all backgrounds, so we won’t mention any specific technologies … but, you know who you are ;)

XML isn’t all horrible – it makes a lot of sense for some applications. But, you can’t get around the fact that XML is annoying as heck sometimes and some applications really need some more flexibility than XML can provide.

A DSL (domain specific language) is a small, special purpose language that’s meant to do a few things, but do them well. An example would be the Gemfile “DSL” that comes with Rails. In fact, the lack of XML was one of the biggest lures of Rails (for me, and most likely for many others).

The thing is, XML is only data. It isn’t a programming language; so, you can’t really express any computations with it. And, it’s not the most readable in many cases.

Web frameworks aren’t the only place where the type of situation arises that XML (or, any other similar data canning format, for that matter) doesn’t make much sense. Vim and Emacs both have domain specific languages. Financial applications, in general, usually have some kind of DSL attached with them. The thing is, a DSL comes with power that no data representation format can offer.

That’s not to say DSLs can’t be used for data representation! They sure can, and, in fact, if designed properly, they work better than many other traditional systems such as XML or JSON.

Back in the “olden days”, DSLs weren’t so easy to write. You had to define the language using a formal method, generate a lexer and parser, and finally compile or interpret the language. It was really a lot of work, because you had write WRITE A FREAKING COMPILER.

But, with dynamic languages, life is much easier and DSLs are really exploding in popularity. The basic idea is, instead of writing a
compiler, we use the power of Ruby itself to help develop the language. We define a few methods and, using these methods, the user of the DSL can accomplish their goal using Ruby. This kind of programming is often termed “metaprogramming“, since it manipulates other code.

The special idea is, unless you really want to, you’re completely hidden away from Ruby. This doesn’t look much like Ruby:

[gist id=”2949777″]

But, it is a very simple DSL that we can use Ruby to define.

So far, we’ve only just talked about it. Let’s get on with actually creating a DSL with Ruby!

Definition

First of all, we need to understand what exactly we want the language to do and what the DSL should look like.

Let’s imagine a robot; he can only move forward, backward, right and left some number of units. We have to keep track of his coordinates in reference to the point where he started, which we will call the origin. He can also fire and we have to keep track of the coordinates at which the robot fires.

That’s a fairly clear description. It might be something used for a website that hosts competitions for robots like these (upload your code and it pits your robot against others). That would be fun if the DSL had a few more features! But, we’ll go with KISS for now.

Now, we need to have some example code to go with this:

[gist id=”2949812″]

Okay, that’s nice. That clearly shows what we want our language to look like. We’ve just got to implement it.

Implementation

Implementing the DSL is incredibly easy, in fact, so easy that you’ll want to do it all the time!

We load a bit of code from a file, and use a special little method called “instance_eval” to run it as Ruby code, but with some special methods given to it. In our DSL, we’ll want to define the methods “forward”, “backward”, “right”, “left” and “fire”.

To do this, we define a class (you can call it anything you want, I’m going to call it Robot):

[gist id=”2949873″]

Add in the methods:

[gist id=”2949894″]

Now, just as a practical demonstration, we add in code that prints out the name of the method called:

We now use instance_eval. It can be used on any (pretty much) any object, and, it takes a block as an argument. Here it is:

[gist id=”2949938″]

That should print out the order of the methods when run. Why is that awesome? Because that shows us that the sky is the limit!

Since we can define whatever the heck we want in the Robot class, creating a DSL becomes very easy and allows for lots of creativity.

Remember, we want to keep track of the coordinates of the robot and the coordinates at which we fired. Let’s tackle the former first.

We begin by adding in the constructor (and getting rid of the “puts” in the methods, which were only there as an example):

[gist id=”2949987″]

We’ve added in the requisite data structures as object variables in order to keep track of information about our beloved robot.

Now, we fill in the movement methods so that they actually modify the information we’re keeping track of:

[gist id=”2950009″]

We add in the “fire” method and the logic needed to store the fired_at locations:

[gist id=”2950025″]

Before testing, we should add in some “puts” so that we can actually see what’s going on:

[gist id=”2950041″]

Finally, we add the instance_eval back in, with a little bit of test code to see if what we’ve developed is on the right track:

[gist id=”2950088″]

With that, you should get an output of the coordinates and fired_at’s of the robot.

That’s how easy it is develop a DSL! As a recap, this is all we did:

• Made a class
• Added methods (optional, although without them a DSL isn’t really anything)
• Added constructor (optional)
• Used instance_eval

That’s all there is to it! No wonder DSLs are so popular – they give us a lot of power for very little code.

Remember that you still have Ruby by your side. Consider this bit of code:

[gist id=”2950128″]

If you run it, you should see that the robot ends on (0, 6). We’ve used Ruby to create some abstraction for the robot, so that we can build bigger programs!

Tips

There a few things to remember while designing DSLs:

• Keep a very simple API – short names, straightforward ideas
• Remember that Ruby’s on your side – use it to its full advantage alongside your DSL
• DSL stands for Domain Specific Language – you’re not trying to invent another Ruby here, so, keep it small
• If the DSL is going to be user inputted onto a server – never trust your users

The last point deserves a bit more explanation. If you’re using the Robot DSL to pit user built robots against one another, in a setting where someone uploads their code onto your server and then your server runs the code, be extremely wary of what your users can do!

DSLs do NOT shield you from what Ruby can do – all of the code should be sandboxed and (basically) all syscall access turned off. Letting external code run wild on your servers will get you hacked before you can say “domain specific language”!

Conclusion

I hope you’ve enjoyed the ride; we’ve developed a domain specific language in about 50 lines of code. That’s pretty awesome!

The sky really is the limit with DSLs! It’s so easy to build them, and even easier to make them better! Just add on or change the methods in the class on which instance_eval is called.

Thanks for reading, and I hope that knowledge will come in handy.