CSC/ECE 517 Fall 2013/ch1 1w30 nn

A domain specific language (DSL) is a computer programming language of limited expressiveness focused on a particular domain. A domain-specific language is created specifically to solve problems in a particular domain and is not intended to be able to solve problems outside it (although that may be technically possible).

Why use DSL ?

DSLs are useful tools – they use the grammar and syntax that closely resembles the lexicon used by the target domain so we can easily express logic specific to the particular problem.They have very specific business domain based implementations. It is designed to be very intuitive and fluent for a domain expert to use.A domain-specific language is similar to programming library and is somewhere between a tiny programming language and a scripting language.

DSLs are popular for two major reasons: improving productivity for developers and improving communication with domain experts.A well-built DSL can make it easier for the developers to understand a complicated workflow thereby increasing their productivity. The communication with the domain experts becomes easier as it provides a bridge between the development of an executable software and a description that the domain experts can understand to know how their requirements have been implemented in the system. This helps to address one of the major concerns in software development- the communication between the developers and the customers.

Lets take for example, a mathematician working on a particular algorithms does not think in loops, iterations and variables but instead he thinks in the form of base cases, recursions and base comparisons. Using a programming or a general purpose language with iterators and loops require him to mentally map the corresponding parameters from his domain to the language he wants to write his code in. Using A DSL for algorithm design can help nullify this translation and provide a much more effective and reusable code library.

Types of DSL

There are two types of DSLs namely Internal and External.

Internal DSL

An internal or embedded DSL is designed and implemented using a host language. A script in an internal DSL is valid code in its general-purpose language, but only uses a subset of the language's features in a particular style to handle one small aspect of the overall system.The programmer need not worry about grammar, parsers, and tools to do the heavy lifting. However, an internal DSL is constrained by the host language, and your DSL is influenced by its host's flexibility, limitations, and idiosyncrasies. The challenge with an internal DSL is to tactfully design the language so that the syntax is within the confines of what the host language allows, yet is as expressive, concise, and fluent as you desire.Ruby has also developed a strong DSL culture: Many Ruby libraries come in the style of DSLs. In particular, Ruby's most famous framework, Rails, is often seen as a collection of DSLs.

Advantages and Disadvantages of Internal DSLs

An internal DSL rides on the syntax of a host language, so the programmer need not spend any time or effort worrying about compiling or parsing. Also as the programmer is largely constrained by the host language, a lot of time is saved designing the syntax of the DSL.or an effective implementation of a DSL a flexible language with great metaprogramming capabilities would be useful.It is better to choose a programming languages which has few restrictions and idiosyncrasies.External DSLs give you better control than internal DSLs when validating DSL syntax. Because you take the effort to define the grammar for your external DSL, that effort also serves to validate the syntax. This is harder to do with an internal DSL because the code is often processed dynamically. You will have to do extensive error checking and do the validation yourself.

External DSL

An external free-standing DSL is a language separate from the main language of the application it works with. Usually, an external DSL has a custom syntax and programmer defined rules for grammar-definitions and parsing the syntax.It is upto the DSL programmer to decide on the language and the tools to implement the DSL. However, using another language's syntax like XML is also common. A script in an external DSL will usually be parsed by a code in the host application using text parsing techniques. Examples of external DSLs that you probably have come across include regular expressions, SQL and XML configuration files for systems like Struts and Hibernate.

Advantages and Disadvantages of External DSLs

An external DSL gives the programmer the liberty to design the syntax of his/her language in exactly the way desired. They can select the language's symbols, operators, constructs, and structure as they fit their domain. On the downside, the programmer has to define the grammar for their language and create a compiler to parse and process the syntax and map it to the semantics they expect. An external DSL gives a programmer a lot of flexibility, but you have to take the time to do the hard work of compiling it.

Building a DSL in Ruby

DSls are quite popular in Ruby because of the nature of the Ruby language itself:

• Especially the ability of Ruby to use minimal syntax in order to make the code concise.
• Ruby being a very expressive language and having readable syntax facilitates writing of DSLs where one has to come up with their own syntax.
• Most ruby programs are already a DSL because of Ruby's syntax.

Below is the actual Ruby code:

it "must not allow a person to login without the proper credentials " do
 person.logs_in_with("invalid credentials");
 person.must_not(be(person.logged_in?()));
end

The above code can also be written as a DSL :

it "must not allow a person to login without the proper credentials " do
 person.logs_in_with :invalid credentials
 person.should_not_be_logged_in
end

From the above example we can clearly see that the DSL code is more readable and clearly explains what the code means. Notice how we used symbols(:invalid credentials) instead of strings to make it more readable.

How to build a DSL in ruby

A general process for writing a DSL in Ruby is as follows :

• The process identification page involves identifying all the processes and functionality to be built into the DSL.
• The second step involves choosing a desired syntax for writing the DSL.
• In the third step we define the interface of the DSL or the API.
• Next we define the classes and various abstraction put in place.
• Finally we implement all the validations.

Good practice for building a Ruby DSL

Follow these good design principles to make a better DSL:

• Always make entities as classes , so that they may correspond to a noun or a realworld entity.

• All operations should be methods, typically use verbs to define an action.

• Use in class definitions as much as possible.

Examples

Here are some examples that will explain the various benefits/use cases of DSLs in Ruby:

Internal DSL in Ruby

• A programmer can create his/her own classes and define them:

class Integer
 def minutes
  .....
 end
end

60.minutes
20.mnutes.later
delete 20.minutes.later

We can see in the above code that the programmer has defined his own class Integer within it a method minutes. On the method he has applied various calls that would result in some action (in this case delete).

• A DSL can be used to write more expressive code

every 3.day, :at => '2.00 pm' do
 delete
end

The above code easily reflects its purpose which is at a particular frequency and at a specific time carry out some action.

• Following is an RSpec code example :

describe Group do
 it "name XYX " do
  x = Group.new
  x.should_not_be_valid
 end
end

• A rails migration is also a DSL

create_table:employees do |x|
  x.string :name
  x.timestamps
end

Notice that in all the above examples the focus is on using your own syntax in making the code concise and easier to use. Herein lies the power of DSL.

Some popular Ruby DSLs

Some popular examples of Ruby DSLs are as follows:

• Rake : [ http://rake.rubyforge.org/]
• Sinatra :[ http://www.sinatrarb.com/]
• Twibot : [ https://github.com/cjohansen/twibot/tree/master]
• Rails
  • routes.rb
  • migrations
• Rspec

Advantages and Disadvantages

Some of the advantages:

• Domain-specific languages allow solutions to be expressed in the idiom and lexicon of the domain.It is possible for the domain experts to themselves define , modify and develop the domain-specific language code.
• It is possible to do validations in DSL’s at the domain level.
• The code in most cases is self-documented
• Domain-specific languages improve quality, productivity, reliability, maintainability, portability and reusability.

Some of the disadvantages:

• There are a lot of overhead costs involved w.r.t developing DSL’s.
• The programmer needs to learn a new language , design, implement, setting and maintaining a scope and maintain a DSL as well as the tools required to develop it.
• Also limited number of experts in a DSL increases the labor costs.
• DSL’s also cause some level of processor efficiency hit as compared to hand-coded software.
• Difficulty of balancing trade-offs between domain-specificity and general-purpose programming language constructs.
• Integration of the DSL with other components of the IT system may be difficult.
• Proliferation of similar non-standard domain-specific languages.Non-technical domain experts can find it hard to write or modify DSL programs by themselves.

Further Reading

• A very comprehensive DSL example can be found here : Building DSL
• Martin Fowler on domain-specific languages
• How to design a Domain Specific Language

References

• Building DSL in Java
• Domain Specific Languages
• How to write your own DSL
• DSL Coding
• DSL construction with Ruby