domain specific languages: a practical view

1

Domain Specific Languages: a practical view

Leandro Marques do NascimentoPh.D. Candidate at UFPE

lmn2@cin.ufpe.br

2

Agenda• Introduction– Concepts– Examples– Types of DSLs– Advantages and disadvantages of using DSLs

• Building a new Domain-Specific Language– Development phases – Understanding DSLs in details– Tools for creating DSLs

• Xtext demo• What community has done so far

3

Introduction

• DSLs offer substantial gains in expressiveness and ease of use compared with general-purpose programming languages in their domain of application [1].

• Problems– DSL development is hard, requiring both domain knowledge and

language development expertise. Few people have both [1]. – The decision to develop a DSL is often postponed indefinitely, if

considered at all, and most DSLs never get beyond the application library stage.

Domain-specific languages (DSLs) are languages tailored to a specific application domain.

4

Examples of DSLs• In addition to Excel, a natural

example of DSL: – AutoCAD for architectural design– ProEngineer for mechanical modeling– Verilog for hardware description – Mathematica for symbolic computing.

5

More examples of DSLs [2]• Language level is related to

productivity DSL Application Domain Level

BNF Syntax specification NA

Excel Spreadsheets 57

HTML Hypertext web pages 22

LATEX Typesetting NA

Make Software building 15

MATLAB Technical computing NA

SQL Database queries 25

VHDL Hardware design 17

----------- -------------------------------------------------- ---------------

Java General-purpose 6 (comparison only)

Level Productivity Average per Staff Month (FP)

1–3 5–10

4–8 10-20

9-15 16-23

16-23 15-30

24-55 30-50

>55 40-100

6

Types of DSLs [3]• Textual DSLs– Textual representation of a language that can be directly (or

indirectly) transformed into executable code– Embedded DSLs

• Mix between General Purpose Languages (GPLs) and Textual DSLs. Usually well know as application libraries (frameworks)

• Visual DSLs (or graphical)– Based on visually representing a system a on incremental

transformations of those visual models into executable code– Synonym for Model Driven * (MDD, MDA, MDSE, etc.)

• Other types– External / Internal

7

DSLs: The good [4]• Targeted abstractions mean DSL programs

express important information & hide details– “You can really see what we’re talking about”– DSLs can dramatically shorten the path between a specification and an

implementation– Programs are shorter, easy do audit, maintain

• Enormous productivity increase

• From declarative abstractions, we can generate multiple artifacts:– Parser, printer, XML transaction, statistical analyzes

• Compiler can ensure properties of programs:– Parser will return meta-data that describes errors

8

DSLs: The bad and the ugly [4]• Challenge of routine features– Include in DSL: replicate a lot of effort!– Borrow from ‘host’ language: have to process host language code

• Lack of tools– DSLs often lack debuggers, profilers, IDE support, etc., because

building them is labor intensive• Reluctant customers– Learning new languages is hard

• Poor documentation and training on new DSLs– Limited knowledge and expertise on how to perform domain

analysis

9

DSLs: the main goal• Gains in expressiveness and ease

of use– The future is end-user programming

10

Caught much attention from both Academia and Industry

• IEEE Transactions on Software Engineering (Vol. 35, No. 6)– Special Section on Software Language Engineering

• The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software EngineeringDaniel L. Moodyhttp://doi.ieeecomputersociety.org/10.1109/TSE.2009.67

• Engineering of Framework-Specific Modeling LanguagesMichał Antkiewicz, Krzysztof Czarnecki, Matthew Stephanhttp://doi.ieeecomputersociety.org/10.1109/TSE.2009.30

• Many different workshops, conferences and symposiums on MD* and DSLs

11

Building a new Domain-Specific Language

First, you should understand DSLs in details

12

Building a new Domain-Specific Language• DSL development phases [1]– Decision

• Decision in favor of a new DSL– Analysis

• Domain knowledge is gathered.– Design

• Relationship between the DSL and existing languages• The formal nature of the design description

– Implementation• Interpreter/Compiler/Application Generators

– Deployment• Started using the new DSL for building up new apps

13

Understanding DSLs in details - DSL classification [5]

• Notation FODA

14

DSL classification [5]

15

DSL classification [5]

16

DSL classification [5]

17

DSL classification [5]

18

DSL Tools with textual modeling [6] • Xtext• TEF (Textual Editing Framework)• TCS (Textual Concrete Syntax)• EMFText

• JetBrains MPS• MontiCore, CodeWorker, IMP• DSL2JDT, ETMOP, CAL

19

DSL Tools with textual modeling [6]• TMF Xtext (predessor oAW Xtext)

– http://xtext.org– http://wiki.eclipse.org/TMF

• TEF Textual Editing Framework– http://www2.informatik.hu-berlin.de/sam/meta-tools/tef– http://developer.berlios.de/projects/tef/

• TCS Textual Concrete Syntax– http://wiki.eclipse.org/index.php/TCS – http://www.sciences.univ-nantes.fr/lina/atl/www/

• EMFText– http://emftext.org– http://st.inf.tu-dresden.de/reuseware/index.php/EMFText

20

DSL Tools with textual modeling [6]• JetBrains MPS– http://www.jetbrains.com/mps– Konstantin Solomatov

• MontiCore– http://www.monticore.de– RWTH Aachen, Academic

• CodeWorker– http://www.codeworker.org/– Cedric Lemaire

• IMP– http://eclipse-imp.sourceforge.net/– Robert M. Fuhrer

21

DSL Example – Chess Game

Using the Chess game to understand DSL construction

22

23

24

25

26

Xtext – Language Development Framework

www.eclipse.org/Xtext/

27

Create a Language• Define the grammar• Add static analysis• Provide quickfixes• Implement an Interpreter

28

Grammar (Simple Arithmetics)• Grammar describes how models can be

parsedModule:'module' name=ID(imports+=Import)*(statements+=Statement)*;

Statement:Definition | Evaluation;

Definition:'def' name=ID ('(' args+=DeclaredParameter (',' args+=DeclaredParameter)* ')')?':' expr=Expression ';';

DeclaredParameter:name=ID;

Evaluation:expression=Expression ';';

Modelmodule SimpleArithmetics

def boxVolume(l,w,h) : l*w*h;

def cubeVolume(l) : boxVolume(l,l,l);

Grammar

29

Chess Example - GrammarGame: "White:" whitePlayer=STRING "Black:" blackPlayer=STRING (moves+=Move)+;

Move: AlgebraicMove | SpokenMove;AlgebraicMove: (piece=Piece)? source=Square (captures?='x'|'-') dest=Square;

SpokenMove: piece=Piece 'at' source=Square (captures?='captures' capturedPiece=Piece 'at' | 'moves to') dest=Square;

terminal Square: ('a'..'h')('1'..'8');

enum Piece: pawn = 'P' | pawn = 'pawn' | knight = 'N' | knight = 'knight' | bishop = 'B' | bishop = 'bishop' | rook = 'R' | rook = 'rook' | queen = 'Q' | queen = 'queen' | king = 'K' | king = 'king';

30

Chess Example - ModelWhite: "Mayfield"Black: "Trinks“

pawn at e2 moves to e4pawn at f7 moves to g5

K b1 - c3f7 - f5

queen at d1 moves to h5// 1-0

31

You can create a new view for your brand new language

32

Community

• http://www.eclipse.org/Xtext/community/– APPlause - Open source tool chain to produce native apps for

different devices such as Android, iPhone and. Heiko Behrens, Peter Friese, et al

– Aranea - Messaging and infrastructure layer that uses Xtext for generating the message and support classes. Patrick Ruckstuhl

– ARText (part of Artop) - ARText, a textual language for the specification of AUTOSAR systems. See the very coolscreencasts. Sebastian Benz, Dana Wong

33

WebDSL [7]application minimalac

entity User { name :: String password :: Secret } init{ var u := User{ name := "1" password := ("1" as Secret).digest() }; u.save(); } define page root(){ authentication() " " navigate protectedPage() { "go" } }

define page protectedPage(){ "access granted" }

principal is User with credentials name, password

access control rules

rule page root(){true} rule page protectedPage(){loggedIn()}

34

References1. M. Mernik, J. Heering, and A. Sloane, “When and how to develop domain-

specific languages,” ACM Computing Surveys (CSUR), vol. Vo.37 N.4, 2005, pp. 316-344.

2. JONES, C. 1996. SPR Programming Languages Table Release 8.2, http://www.theadvisors.com/ langcomparison.htm. (Accessed April 2005). Later release not available at publication.

3. M. Völter, “MD*/DSL Best Practices Update March 2011,” 2011, Available at http://voelter.de/data/pub/DSLBestPractices-2011Update.pdf, Accessed in March 2011.

4. J. Gray, K. Fisher, C. Consel, G. Karsai, M. Mernik, and J.-P. Tolvanen, “Panel - DSLs: The Good, the Bad, and the Ugly,” OOPSLA ’08: Companion to the 23rd annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, 2008, Available at http://www.infoq.com/presentations/Truth-about-DSL, Accessed in March 2011.

5. B. Langlois, C.E. Jitia, and E. Jouenne, “Dsl classification,” OOPSLA 7th Workshop on Domain Specific Modeling, Citeseer, 2007.

6. Bernhard Merkle, “Textual Modeling Tools: Overview and Penalty Shoot-out ”, EclipseCON 2010, Available at www.infoq.com/presentations/Textual-Modeling-Tools, Accessed in March 2011.

7. WebDSL. http://webdsl.org/, Accessed in March 2011.

35

“If you can't make it good, at least make it look good.”Bill Gates

Questions?

Domain Specific Languages: a practical view

Leandro Marques do Nascimento

Ph.D. Candidate at UFPElmn2@cin.ufpe.br