domain-specific languages: challenges and opportunities zhanyong wan yale university

Domain-Specific Languages:Challenges and Opportunities

Zhanyong Wan

Yale University

DS

L F

RP

Zhanyong Wan, 3/27/2002 Yale University 2

State-of-the-art in software production

Programs are buggy Bugs are difficult to find / fix Consequences of bugs can be costly

More and more of our life depends on software Aircraft engines, smart weapons, computerized

medical equipments, nuclear power plants, national and global economy, etc

Round-off error caused the Patriot missile to overlook a Scud; 28 killed (Jan 25, 1991)

A Y2K bug struck at the Shika nuclear plant in Japan, shutting down a radiation alarm system (Jan 1, 2000)

Buffer overflow: Morris worm, etc (many times) Many errors go undetected!

DS

L F

RP


How do we make reliable software?

Relying on testing is not good enough We want guaranteed correctness / safety Good programming languages can (help) provide

strong guarantee on correctness / safety Languages should be declarative

Bugs are introduced in translating spec to code Languages should utilize formal methods

Advanced type systems Formal semantics Formal verification / proof techniques

Slogan: declarative languages that utilize formal methods

DS

L F

RP


Language affects thinking

“Language shapes the way we think, and determines what we can think about.” – B.L.Whorf, linguist

“If thought corrupts language, language can also corrupt thought.” – George Orwell, novelist

Languages are frameworks for models and solutions

DS

L F

RP


But this is a complex world…

Computers are used in many different domains Databases, finance, scientific computation, communication,

military, etc Domains vary in:

What is considered declarative What properties of a program we want to formally ensure

No single programming language can apply to all the domains!

DS

L F

RP


We need domain-specific languages

A domain-specific language (DSL) is a language tailored for a particular problem domain

A good DSL captures the right abstraction of the domain, no more and no less

Hides unnecessary details Provides enough control on what the programmer cares about Is declarative!

DS

L F

RP


My contribution

Semantics, design, implementation, and applications of the Functional Reactive Programming (FRP) DSL

What does a program mean?

Is the implementation

correct?

FRP from first principles

Wan and Hudak, PLDI ’00

The FRP language and libraries for animation and

robotics.

FRP user’s manualPeterson, Wan, Hudak, and Nilsson

Yale CS-TR, ’01

How do we adapt FRP for systems where response

time must be bounded?

Real-time FRPWan, Taha, and Hudak, ICFP ’01

How do we compile FRP to efficient low-

level code?

Event-driven FRPWan, Taha, and Hudak, PADL ’02

DS

L F

RP


Rest of the talk

Functional Reactive Programming (FRP) Animation

FRP for embedded systems Resource bound

FRP for event-driven systems Robot control Game scripting

Conclusions

DS

L F

RP


Functional Reactive Programming (FRP)

Hybrid reactive systems Hybrid

Have both continuous and discrete components Reactive

Continually react to stimuli Examples

Animation, robotics, control systems, etc Highlights of FRP

Declarative: Continuous-time-varying entities Focuses on model rather than presentation

Formal semantics

environ-ment

environ-ment

(hybrid)reactivesystem

stimuli responses

DS

L F

RP


Applications of FRP

Have been successfully used in: Interactive animation: Fran (MS Research) Graphical User Interface: FranTk (U Glasgow)

Fruit (Yale, MS Research) Vision: FVision (Yale, JHU) Theater lighting control: Lula (U Tübingen) Robotics: Frob (Yale, JHU) Real-time systems: RT-FRP (Yale) Event-driven systems: E-FRP (Yale)

DS

L F

RP


FRP basic notions

Behaviors Values that vary over continuous time

Example: animation Implemented by sampling Sampling is hidden from the user

Events Discrete event occurrences

time

behavior

time

event

DS

L F

RP


FRP basic operations

Behaviors and events are both first-class Passed as arguments Returned by functions Stored in data structures

Combinators combine small behaviors / events into bigger ones

sin b, integral b, e1 .|. e2, when b

Ordinary functions can be lifted to work on behaviorsf :: a -> blift f :: Behavior a -> Behavior b

Behaviors can react to eventsb `until` e -=> b’

Backquotes for infix operator

DS

L F

RP


Paddle ball in four easy steps

Step 1. walls: spatial composition

walls = let upper = rect (0, 0.1) ( 7, 0) left = rect (0, 7) (0.1, 0) right = rect (6.9, 7) ( 7, 0) in withColor blue (right `over` left `over` upper)

0 7

7

over combines two animations

into one

upper, left, rightare “still animations”

juxtaposition for function application!

DS

L F

RP



Step 2. paddle: reacting to mousewalls = let upper = rect (0, 0.1) ( 7, 0) left = rect (0, 7) (0.1, 0) right = rect (6.9, 7) ( 7, 0) in withColor blue (right `over` left `over` upper)

paddle = withColor red (moveXY (xCoord mouse) 6.2 (rect (-0.4, 0) (0.4, 0.1)))

mouse is the position of mouse, a

behavior of point

moveXY x y a translates

animation a by (x, y)

DS

L F

RP



Step 3. ball: model of motionwalls = let upper = rect (0, 0.1) ( 7, 0) left = rect (0, 7) (0.1, 0) right = rect (6.9, 7) ( 7, 0) in withColor blue (right `over` left `over` upper)


ball vel = let xpos = 3 + integral xvel xvel = vel `stepAccum` xbounce -=> negate xbounce = when (xpos > 6.7 || xpos < 0.3) ypos = 3 + integral yvel yvel = vel `stepAccum` ybounce -=> negate ybounce = when (ypos < 0.3 || ypos `between` (6, 6.3) && xCoord mouse `between` (xpos - 0.4, xpos + 0.4) in moveXY xpos ypos (shrink 4 (withColor yellow circle))

stepAccum updates a

behavior when an event occurs

recursive definitions: xpos, xvel

:: Behavior Real

xbounce :: Event

DS

L F

RP



Step 4. put them together!walls = let upper = rect (0, 0.1) ( 7, 0) left = rect (0, 7) (0.1, 0) right = rect (6.9, 7) ( 7, 0) in withColor blue (right òver` left òver` upper)


ball vel = let xvel = vel `stepAccum` xbounce -=> negate xbounce = when (xpos > 6.7 || xpos < 0.3) xpos = 3 + integral xvel yvel = vel `stepAccum` ybounce -=> negate ybounce = when (ypos < 0.3 || ypos `between` (6, 6.3) && xCoord mouse `between` (xpos - 0.4, xpos + 0.4) ypos = 3 + integral yvel in moveXY xpos ypos (shrink 4 (withColor yellow circle))

paddleball = animate (walls òver` paddle òver` ball 1.5)

animate runs an animation

DS

L F

RP



DS

L F

RP


But what does it all mean?

We want the exact meaning of a program: its semantics

Using semantics we can transform and optimize programs while

preserving their meanings prove important properties of programs

Example: engine never runs in full power for more than 5 minutes

DS

L F

RP


Semantics of FRP

The semantics of a behavior is a function from time to value

[b] t is the value of b at time t:

[b1 + b2] t = [b1] t + [b2] t[integral b] t = s0

t ([b] detc

time

value

DS

L F

RP


Implementation of FRP

The implementation Based on sampling An approximation to the semantics

time

value

Semantics (ideal)

Implementation (approximation)

Will the implementation converge to the semantics?

Under suitable conditions, yes. (PLDI ’00) Uniformly continuous functions + uniformly convergent behaviors

Conditions for identifying bad programs

DS

L F

RP


Expand the territory of FRP

Our experience was that FRP is fast enough for most of the applications we had considered

Animation User interfaces High-level robot controllers

We want to use FRP for Embedded systems Real-time systems

Problem: FRP does not guarantee space / time bound

DS

L F

RP


Restricting FRP

FRP

All FRP programs

Bad

FRP programs with bad space / time behaviors

(undecidable!)Accepted

FRP programs that we accept(the more the better!)

Result (ICFP ’01):

Real-Time FRP (RT-FRP), a subset of FRP, with guaranteed bounds on execution time and space, and reasonably expressive (practical for embedded systems)

DS

L F

RP


Real-Time FRP (RT-FRP)

Base language + reactive language Base language

Provides operations on static values Can be any resource-bounded pure

language Reactive language

Provides temporal operations Local state Reaction

Main contribution Reactive language is space / time

bounded

reactive language

b `until` e -=> b’

base language

x+5, y and (not z)

RT-FRP

DS

L F

RP


Talk about resources

To measure the cost of running a program, we define an operational semantics for RT-FRP

“on input i, p yields r and is updated to p’.” The time and space needed for executing

are bounded by the size of p Execution of a program

p i r; p’

p i1 r1; p1p1 i2 r2; p2

… environ-ment

environ-ment

reactivesystem

p

i1

environ-ment

environ-ment

reactivesystem

p1

r1

environ-ment

environ-ment

reactivesystem

p1

i2

environ-ment

environ-ment

reactivesystem

p2

r2

p i r; p’

DS

L F

RP


How we ensure resource bound

We use syntax and type system to restrict the form of recursion

General recursion is not allowed The user can use two restricted forms of recursion

We proved the following theorem for RT-FRP: p, N, input sequence i1, i2, …, and

p i1 v1;p1, p1 i2 v2;p2, …, we have |pk| < N for all k > 0.

DS

L F

RP


Crouching robots, hidden camera

RoboCup

camera

radioradio

Team Bcontroller

Team Acontroller

DS

L F

RP


A Simple RoboCup Controller

A toy example of an embedded system

• 1 radio receiver

• 2 wheels, 2 motors, 2 IR’s

• 1 PIC micro-controller

DS

L F

RP


Simple RoboCup Controller (SRC)

dutycycle

desiredspeed

speed

M

IR

ClkFastClkSlow

IncSpdDecSpd

0-100

0/1

0-100

power

behavior

event

delaySRC

count

DS

L F

RP


Event-driven FRP

The E-FRP (Event-driven FRP) language (PADL ’02) A subset of RT-FRP

Payoff of the restrictions An E-FRP compiler that

Generates efficient C code for PIC16C66 MCU, and Is provably correct

Preserves semantics Generates resource bounded target code Makes the target program more reliable!

DS

L F

RP


SRC in E-FRP

Source codeds = init 0 on IncSpd => ds + 1, DecSpd => ds - 1

s = init 0 on IR => s + 1, ClkSlow => 0 later

dc = init 0 on ClkSlow => if s < ds then dc + 1 else if s > ds then dc - 1 else dc

count = init 0 on ClkFast => if count >= 100 then 0 else count + 1

power = if count < dc then 1 else 0

dutycycle

desiredspeed

speed

power

SRC

count

DS

L F

RP


SRC in two languages

E-FRPds = init 0 on IncSpd => ds + 1, DecSpd => ds - 1





Cinit() { ds = s = dc = count = power = 0;}

onIncSpd() { ds++; }

onDecSpd() { ds--; }

onIR() { s++; }

onClkFast() { count = count >= 100 ? 0 : count + 1; power = count < dc ? 1 : 0;}

onClkSlow() { dc = s < ds ? dc + 1 : s > ds ? dc – 1 : dc; power = count < dc ? 1 : 0; s = 0;}

dutycycle

desiredspeed

speed

power

SRC

count

DS

L F

RP











onIR() { s++; }



dutycycle

desiredspeed

speed

power

SRC

count

DS

L F

RP











onIR() { s++; }



dutycycle

desiredspeed

speed

power

SRC

count

Plus, E-FRP guarantees resource bound!

DS

L F

RP


MindRover

Robot simulation environment Build your own robots

Wide variety of components: sensors, actuators Program them as event-driven systems

Visual builder: intuitive but limited Scripting language: ICE, event handlers

Go! Simulation of physics

Have packages for LEGO robots and OOPic micro-controller Can be used to test control algorithms at minimal cost!

DS

L F

RP


Killer Hovercraft

radars

rocketlaunchers

thrusters

DS

L F

RP


Controlling killer hovercraft in E-FRP

fRadar.angle = 0fRadar.scanWidth = 5fRadar.maxRange = 10 …-- the same for lRadar and rRadarenemyDir = init dUnknown on fRadar.TurnOn => dAhead, lRadar.TurnOn => dLeft, rRadar.TurnOn => dRight

lThruster.thrust = if enemyDir == dLeft then –50 else 50

rThruster.thrust = if enemyDir == dAhead || enemyDir == dLeft then 50 else -50

rocket.Fire <= fRadar.TurnOn

DS

L F

RP


Conclusions

DSL’s are fun Interesting applications

DSL’s are useful Help domain experts solve problems Have an impact on the real world

DSL’s are challenging research Creating DSL’s for many other domains

Tons of them: computational biology, financial engineering, etc Proving properties of DSL’s Developing tools for developing DSL’s

Rapid prototyping of DSL’s Domain-specific type systems Domain-specific optimization Domain-specific verification

domain-specific languages: challenges and opportunities zhanyong wan yale university

Documents