Abstract

In general, designing a domain-specific language (DSL) is a complicated process, requiring the cooperation of experts from both application domain and computer language development areas. One of the problems that may occur is a communication gap between a domain expert and a language engineer. Since domain experts are usually non-technical people, it might be difficult for them to express requirements on a DSL notation in a technical manner. Another compelling problem is that even though the majority of DSLs share the same notation style for representing the common language constructs, a language engineer has to formulate the specification for these constructs repeatedly for each new DSL being designed. The authors propose an innovative concept of computer language patterns to capture the well-known recurring notation style often seen in many computer languages. To address the communication problem, they aim for the way of proposing a DSL notation by providing program examples as they would have been written in a desired DSL. As a combination of these two ideas, the chapter presents a method for example-driven DSL notation specification (EDNS), which utilizes computer language patterns for semi-automated inference of a DSL notation specification from the provided program examples.

Motivation

Scenario 1: Communication with Domain Experts

Anna works as a developer for a global market company. Until now, the goods between stores and warehouses have been ordered and delivered according to handwritten enquiries. To improve this process, the company decided to go for automation. However, as the style used for writing the enquiries has been retained over the years and many employees are used to it, the company wants to keep it in the electronic version as well.

The task that Anna has been assigned is to develop a language with the well-known structure and notation defined by existing enquiries. The approach to specifying a language notation by providing example documents is also very convenient even if documents do not exist and have to be created at first. This is very common in development of vertical DSLs1 since for the non-technical domain experts, writing down the examples is often the best way of communicating their thoughts on the look and feel of a language being designed.