pictures: sxc.hu

pictures: sxc.hu

(Alt.) Domain-Specific Languages: Projectional Edition

Sébastien Mosser (UNS, I3S) Journée IDM, ENSEEIHT, 11.12.15

Sébastien Mosser

•12-…: Associate Professor, UNS

•11-12: Research Scientist, SINTEF (NO)

•10-11: Postdoc, Inria Lille Nord-Europe

•2010: PhD Thesis

"geek, snowboarder & composition-driven guy"

Sébastien Mosser

•12-…: Associate Professor, UNS

•11-12: Research Scientist, SINTEF (NO)

•10-11: Postdoc, Inria Lille Nord-Europe

•2010: PhD Thesis

"geek, snowboarder & composition-driven guy"

DSLDSLDSL

DSL DSL DSL

4

4

5

Bibliography

[Fowler] [Voelter]

Sébastien Mosser, Philippe Collet, Mireille Blay-Fornarino. “Exploiting the Internet of Things to Teach Domain Specific Languages and Modeling” in Proceedings of the 10th Educators' Symposium at MODELS 2014 (EduSymp'14), ACM, IEEE, pages 1-10, Springer LNCS, Valencia, Spain, 29 september 2014

Seriously?

https://github.com/mosser/ArduinoML-kernel

EJCP’15

http://www.dailymotion.com/video/x3b6q8g_toa-mata-band-le-premier-groupe-de-robots-lego_music?start=40

1 243

External DSLs

Alternatives to External DSLs

Projectional Edition

Meta-programming system

1External DSLs ?

Delimiter-directed Translation

14

How It Works

Delimiter-Directed Translation works by taking the input and breaking it down into smaller chunks based on

some kind of delimiter character. You can use any delimiter characters you like, but the most common first

delimiter is the line ending, so I'll use that for my discussion.

Breaking up the script into lines is usually pretty simple, as most programming environments have library

functions that will read an input stream a line at a time. One complication you may run into is if you have long

lines and want to break them up physically in your editor. In many environments, the simplest way to do this is

to quote the line ending character; in Unix this means using backslash as the last character on a line.

Quoting the line ending looks ugly, however, and is vulnerable to whitespace between the quote and the end of

line. As a result, it's often better to use a line continuation character. To do this, you choose some character

that, if it's the last non-whitespace character on a line, indicates that the next line is really the same line. When

you read in the input, you have to look for the line continuation character and if you see it, patch the next line

onto the line you've just read. When you do this, remember you may get more than one continuation line.

How you process the lines depends on the nature of the language you're dealing with. The simplest case is

where each line is autonomous and of the same form. Consider a simple list of rules for allocating frequent

sleeper points for hotel stays.

score 300 for 3 nights at Bree score 200 for 2 nights at Dol Amroth score 150 for 2 nights at Orthanc

I call the lines here autonomous since none of them affect the other ones. I could safely reorder and remove

the lines without changing the interpretation of any line. They're of the same form because each one encodes

the same kind of information. Processing the lines is therefore quite simple; I run the same line processing

Easy

Limited

Syntax-directed Translation

15

Computer languages naturally tend to follow a hierarchical structure with multiple levels of context. We can

define the legal syntax of such a language by writing a grammar that describes how elements of a language get

broken down into subelements.

Syntax-Directed Translation uses this grammar to define the creation of a parser that can turn input text into a

parse tree that mimics the structure of the grammar rules.

How It Works

If you've read any book on programming languages, you'll have come across the notion of a grammar. A

grammar is a way of defining the legal syntax of a programming language. Consider the part of my opening

state machine example that declares events and commands:

events doorClosed D1CL drawerOpened D2OP # ... end commands unlockPanel PNUL lockPanel PNLK # ... end

These declarations have a syntactic form that can be defined using the following grammar:

declarations : eventBlock commandBlock; eventBlock : Event-keyword eventDec* End-keyword; eventDec : Identifier Identifier;

[Domain-Specific Languages]

Figure . A syntax tree and a semantic model are usually different representations of a DSL script.

I've been talking about the syntax tree as if it's a tangible data structure in your system, like the XML DOM.

Sometimes it is, but often it isn't. A lot of the time the syntax tree is formed on the call stack and processed as

we walk it. As a result, you never see the whole tree, just the branch that you are currently processing (which

is similar to the way XML SAX works). Despite this, it's usually helpful to think about a ghostly syntax tree

hiding in the shadows of the call stack. For an internal DSL, this tree is formed by arguments in a function call

(Nested Function) and by nested objects (Method Chaining). Sometimes, you don't see a strong hierarchy and

you have to simulate it (Function Sequence with the hierarchy simulated with Context Variables). The syntax

tree may be ghostly, but it's still a useful mental tool. Using an external DSL leads to a more explicit syntax

tree; indeed, sometimes you actually do create a full-blown syntax tree data structure (Tree Construction). But

even external DSLs are commonly processed with the syntax tree forming and pruning continuously on the call

stack. (I've referenced a few patterns above that I haven't described yet. You can safely ignore them on your

first read, but the references will be helpful on a later pass.)

Grammars, Syntax, and Semantics

When you work with a language's syntax, an important tool is a grammar. A grammar is a set of rules which

describe how a stream of text is turned into a syntax tree. Most programmers have come across grammars at

some point in their lives, as they are often used to describe the programming languages we all work with. A

grammar consists of a list of production rules, where each rule has a term and a statement of how it gets

broken down. So, a grammar for an addition statement might look likeadditionStatement := number '+'

number. This would tell us that if we see the language sentence 5 + 3, the parser can recognize it as an

addition statement. Rules mention each other, so we would also have a rule for a number telling us how to

recognize a legal number. We can compose a grammar for a language with these rules.

[Domain-Specific Languages]

When I started working with EMF / XText

After 6 years

Time to

change!

2Alternatives to

Externals DSLs

21

Graphical DSL

e.g., enterprise integration patterns

21

Graphical DSL

e.g., enterprise integration patterns

still

external

Embedded DSL

23

24

25

3Projectional Edition

In previous episodes …

27

meta-modeling framework

model-driven grammars

28

Teaching Model Driven Engineering

from a Relational Database Perspective

Don Batory1, Eric Latimer1, Maider Azanza2

1 University of Texas at Austin, Austin, TX 78712 USAbatory@cs.utexas.edu, e@utexas.edu

2 University of the Basque Country (UPV/EHU), San Sebastian, Spainmaider.azanza@ehu.es

Abstract. We reinterpret MDE from the viewpoint of relational databases toprovide an alternative way to teach, understand, and demonstrate MDE usingconcepts and technologies that should be familiar to undergraduates. We use (1)relational databases to express models and metamodels, (2) Prolog to expressconstraints and M2M transformations, (3) Java tools to implement M2T andT2M transformations, and (4) OO shell-scripting languages to compose MDEtransformations. Case studies demonstrate the viability of our approach.

1 Introduction

Model Driven Engineering (MDE) is a standard technology for program specificationand construction. We believe it is essential to expose undergraduates to MDE concepts(models, metamodels, M2M, M2T, T2M transformations, constraints, and bootstrapping),so that they will have an appreciation for MDE when they encounter it in industry. Ourmotivation was experience: unless students encounter an idea (however immature) inschool, they are less likely to embrace it in the future. Further, teaching MDE is intimately

related, if not inseparable, to the tools and languages that make MDE ideas concrete.

Our initial attempt to do this (Fall 2011) was a failure. We used the Eclipse ModelingTools3 and spent quite some time creating videos for students to watch, both for instal-lation and for tool usage. For whatever reason, installation for students was a problem.A version of Eclipse was eventually posted that had all the tools installed. The resultswere no better when students used the tools. A simple assignment was given to drawa metamodel for state diagrams (largely something presented in class) using Eclipse,let Eclipse generate a tool for drawing state diagrams, and to use this generated tool todraw particular state diagrams. This turned into a very frustrating experience for moststudents. 25% of our upper-division undergraduate class got it right; 50% had mediocresubmissions, and the remaining just gave up. Another week was given (with tutorial help)to allow 80% to “get it right”, but that still left too many behind. The whole experienceleft a bitter taste for us, and worse, our students. We do not know if this is a typical

situation or an aberration, but we will not try this again.

3 Specifically EMT, Graphical Modeling Tooling Framework Plug-in, OCL Tools Plug-in, andEugenia for Eclipse 3.6.2.

Eclipse emphasizes a medieval approach of modeling, based on incantations

- Don Batory, MODELS’13

"

Never disagree with a Texan guy without (very) strong arguments. Never ever.

Note to self:

[based on Campagne’s slides]

Text Editor

compilerlexer

source

parser

AST

error detection

code gen.optimizer exec.

Storing programs

as text

is so 1950

[based on Campagne’s slides]

AST

exec.

projectionStructure

Generators

Text Editor

source

buildcompilers

source

X

X

Programs are not text anymore!

The AST is the key

AST

Run:! bot: MyBot!! budget: 100! WOOD <- 400! FLOWER <- 40!! ...

P1(AST) P2(AST)Champ [#49]! players: 3A! ! excl: "QAB"!! Contract:! W: 100! F: 40

Is projectional edition an hipster trap?

http://jeffgreenspan.com/projects/personal-work/urban-traps

4Meta Programming

System

https://github.com/mosser/ArduinoML-kernel/blob/master/externals/mps/mps_lab.pdf

Language & Environment

40

Language (~metamodel)

Modeling Environment

conforms to

Meta-modeling a "Circle" (concept)

41

centerX: Int centerY: Int radius: Int

Circle

root

Defining a projection for Circle

42

3. Rebuild1. Add Editor

2. DSL for projection

Project(AST) ↦ Syntax

43

↦

↦

centerX = 0 centerY = 0 radius = 200

: Circle

↦

Generating Code

44

Preview

"mock"

Digression: Language Composition

45

Generator uses ( Java ⊙ Collections )

reduce collections BEFORE reducing shapes

shapeML extends Collections shapeML uses Collections

Reduction Rules

47

Block statement

Template fragment

Template must be compiler compliant

Model-aware generation

48