DSL concepts, categories, and why to write DSL 1

DSL Concept

Martin FowlerDefines a domain-specific language (DSL) as "a computer language that's targeted to a particle kind of problem, rather than a general purpose language that's aimed at any kind of software problem"

Domain-specific agesAren't a new idea by any means. dsls have been around since long before the start of computing. People have always developed specialized

Vocabularies for specialized tasks.

Regular Expressions and SQLAre similarly specialized versions: both are available ages designed for a narrow domain-text processing and database querying, respectively.

Both are focused on letting you express what you mean, not how the implementation shoshould work-that's left to some magic engine in the background.

The reason these versions are so successful is that the focus they offer is incredibly useful. They reduce the complexity that you need to handle, and they're flexible in

Terms of what you can make them do.

DSL type External dsls

Dsls that exist outside the confines of an existing language. SQL and regular expressions are two examples of external dsls.

Common tools for building external dsls include Lex, YACC, anlr, gold parser,

And Coco/R, among others. Those tools handle the first stage, translating text in

Known syntax to a format that a computer program can consume to produce execut-

Able output. The part about "producing executable output" is usually left as an Exer-

Cise for the reader.

Graphical dsls

Uses shapes and lines to express intent rather than using text.

UML is a good example of a graphical DSL

Microsoft has the Visual Studio DSL tools, which is a framework that allows you

To build tools similar to the class designer and generate code with them.

Fluent Interfaces

Fluent interfaces are ways to structure your API so that operations flow naturally and

Provide more readable code. They tend to be valid only when used by hour sdur-

Ing actual development, which limits their scope compared to other dsls.

New Pipeline ("rhino.png ")

. Rotate (90)

. Watermark ("mocks ")

. Roundcorners' (100, color. bisque)

. Save ("fluent-rhino.png ");

User. findall (

Where. User. City = "London "&&

Where. User. registeredat> = datetime. Now. addmonths (-3)

);

Registry. addinstanceof <iwidget> ()

. Withname ("darkgreen ")

. Usingconcretetype <colorwidget> ()

. Withproperty ("color"). Similar to ("darkgreen ");

Internal or embedded dsls

Internal dsls are built on top of an existing language, but they don't try to remain

True to the original programming language syntax. They try to express things in a way

That makes sense to both the author and the reader, not to the compiler.

Obviusly, the expressiveness of an internal DSL is limited by whatever constraints

Are imposed by the underlying language syntax. You can't build a good DSL on top

C # or Java; they have too much rigidity in their syntax to allow it. You probably cocould

Build a good DSL on C ++, But it wowould probably include Preprocessor macros galore,

And I wouldn't place any bets on how maintainable it wocould be.

The popular choices for building internal dsls are dynamic languages ages; lisp and

Smalltalk were probably the first common choices. Today, people mostly use Ruby,

Python, and Boo.

Rake

Task: default => [: Test]

Task: test do

Ruby "test/unittest. RB"

End

 

 

Other features that usually appear in dynamic versions are also useful when building dsls: closures, macros, and duck typing.

The major advantage of an internal DSL IS that it takes on all the power of the LAN-

Uage it's written for. You don't have to write the semantics of an if statement, or

Edefine operator precedence, for instance. Sometimes that's useful, and in one of my

DSL implementations I did redefine the if statement, but that's probably not a good

Hing to do in general, and it's rarely necessary.

 

A DSL built on top of an existing language can also be problematic, because you

Want to limit the options of the language to clarify what is going on. The DSL

Houldn't be a full-fledged programming language; you already have that in the base

Anguage, after all.

The main purpose of an internal DSLIs to reduce the amount of work required

Make the compiler happy and increase the clarity of the Code in question.

The other purpose is to expose the domain. A dslshocould be readable by someone who is familiar with the domain, not the programming language.

Why write DSL?

LTechnical DSL: Making a technical issue or task simpler

This works well if your target audience is developers.

LService DSL: Expressing rules and actions in a way that's close to the domain and understandable to businesspeople

A business DSL needs to be (at the very least) readable to a businessperson with no

Background in programming. This type of DSL is mainly expressive in terms of

Domain, and it has a lot less emphasis on the programming features that may still exist.

LExtended and automated DSL: Automating tasks and actions, usually as part of adding scriptability and extensibility features to your applications. Automatic or extensible dsls may also be called it dsls. This type of DSL is often

Used to expose the internals of an application to the outside world.

For example, modern Games are usually engines configured with some sort of scripting language. another use for this style of DSL wocould be to get into the internals of an application and manage it.

 

Reference books: dsls in BOO domain-specific ages in. net