ADP
Domain specific languages (DSL) are around for quite some time and widely in use for software
development. In this article we will discuss what DSLs are and their characteristics,some basic concepts of
computer science language theory relevant to DSL and finally an example of DSL implementation using
.NET.
A domain specific language (DSL) is a computer programming language of limited expressiveness that is
focused on a particular domain. A DSL is worthwhile and conveys meaning only in the context of the
particular domain.
The characteristic which makes DSL distinct from general purpose languages is ‘limited expressiveness’.
With a general purpose language like Java or C#, we can build almost any kind of system- small or big, PC or
mobile or web enabled, with rich user interface or no user interface at all and in any functional domain like
banking, HR etc. This requires supporting different data structures, control flow, abstraction and many
more features. This also makes these languages too vast and difficult to understand or master for nonprogrammers.
On the other hand, a DSL being focused on a particular problem domain can be defined using bare
minimum of syntactical rules which are sufficient for the domain in question. This makes it possible to
define a DSL which closely resembles a natural language like English (with a very small subset of words and
strict syntactical rules). So it becomes easier for non-programmers like domain experts and business
analysts to understand if not write programs in DSL.
development. In this article we will discuss what DSLs are and their characteristics,some basic concepts of
computer science language theory relevant to DSL and finally an example of DSL implementation using
.NET.
A domain specific language (DSL) is a computer programming language of limited expressiveness that is
focused on a particular domain. A DSL is worthwhile and conveys meaning only in the context of the
particular domain.
The characteristic which makes DSL distinct from general purpose languages is ‘limited expressiveness’.
With a general purpose language like Java or C#, we can build almost any kind of system- small or big, PC or
mobile or web enabled, with rich user interface or no user interface at all and in any functional domain like
banking, HR etc. This requires supporting different data structures, control flow, abstraction and many
more features. This also makes these languages too vast and difficult to understand or master for nonprogrammers.
On the other hand, a DSL being focused on a particular problem domain can be defined using bare
minimum of syntactical rules which are sufficient for the domain in question. This makes it possible to
define a DSL which closely resembles a natural language like English (with a very small subset of words and
strict syntactical rules). So it becomes easier for non-programmers like domain experts and business
analysts to understand if not write programs in DSL.
Some examples of DSLs which we use in everyday programming are HTML (domain- Web user interface),
Sql (domain- RDBMS) or CSS (domain- HTML styling). These are examples of ‘external’ DSLs which are
completely different from general purpose languages and do not use any feature of a general purpose
language.
However it is possible to create a so-called ‘internal’ DSL within a general purpose language itself that uses
only limited features of that language. One such example is ‘Fluent Interface’ pattern in C# which uses a
special chaining syntax for method call and is suitable where C# code needs to be mixed with other
languages like HTML (e.g. ASP.NET MVC View pages).
Rule engines are closely related to DSL but they are different from DSL because of the fact that rule engines
are also general purpose rather than focused on a specific domain. However rule engines often uses some
form of DSL for defining the rules. For example, IBM JRULE rule engine uses an Xml based DSL for defining
rules and Microsoft .NET Workflow Foundation rule engine uses a C# internal DSL for rule definition.
The implementation of an external DSL requires a DSL script, a parser and optionally a code generator. The
DSL script adheres to the limited grammatical or syntactical rules defined for the DSL. The parser parses the
DSL to generate an instance of the domain model specific to the domain in consideration. This domain
model is the crux of the design and should be conceptualized prior to designingthe DSL. The domain model
drives the design of the DSL and parser. The generated instance of the domain model is manipulated by the
application code to produce the DSL program output. Optionally the domain model can be further
processed to generate code in some general purpose language like Java or C# which is then compiled and
executed just like hand written code.
Sql (domain- RDBMS) or CSS (domain- HTML styling). These are examples of ‘external’ DSLs which are
completely different from general purpose languages and do not use any feature of a general purpose
language.
However it is possible to create a so-called ‘internal’ DSL within a general purpose language itself that uses
only limited features of that language. One such example is ‘Fluent Interface’ pattern in C# which uses a
special chaining syntax for method call and is suitable where C# code needs to be mixed with other
languages like HTML (e.g. ASP.NET MVC View pages).
Rule engines are closely related to DSL but they are different from DSL because of the fact that rule engines
are also general purpose rather than focused on a specific domain. However rule engines often uses some
form of DSL for defining the rules. For example, IBM JRULE rule engine uses an Xml based DSL for defining
rules and Microsoft .NET Workflow Foundation rule engine uses a C# internal DSL for rule definition.
The implementation of an external DSL requires a DSL script, a parser and optionally a code generator. The
DSL script adheres to the limited grammatical or syntactical rules defined for the DSL. The parser parses the
DSL to generate an instance of the domain model specific to the domain in consideration. This domain
model is the crux of the design and should be conceptualized prior to designingthe DSL. The domain model
drives the design of the DSL and parser. The generated instance of the domain model is manipulated by the
application code to produce the DSL program output. Optionally the domain model can be further
processed to generate code in some general purpose language like Java or C# which is then compiled and
executed just like hand written code.
