Domain-Specific Languages: Challenges and Opportunities Zhanyong Wan Yale University.
-
Upload
patience-chandler -
Category
Documents
-
view
215 -
download
3
Transcript of 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
Zhanyong Wan, 3/27/2002 Yale University 3
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
Zhanyong Wan, 3/27/2002 Yale University 4
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
Zhanyong Wan, 3/27/2002 Yale University 5
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
Zhanyong Wan, 3/27/2002 Yale University 6
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
Zhanyong Wan, 3/27/2002 Yale University 7
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
Zhanyong Wan, 3/27/2002 Yale University 8
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
Zhanyong Wan, 3/27/2002 Yale University 9
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
Zhanyong Wan, 3/27/2002 Yale University 10
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
Zhanyong Wan, 3/27/2002 Yale University 11
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
Zhanyong Wan, 3/27/2002 Yale University 12
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
Zhanyong Wan, 3/27/2002 Yale University 13
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
Zhanyong Wan, 3/27/2002 Yale University 14
Paddle ball in four easy steps
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
Zhanyong Wan, 3/27/2002 Yale University 15
Paddle ball in four easy steps
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)
paddle = withColor red (moveXY (xCoord mouse) 6.2 (rect (-0.4, 0) (0.4, 0.1)))
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
Zhanyong Wan, 3/27/2002 Yale University 16
Paddle ball in four easy steps
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 `over` left `over` upper)
paddle = withColor red (moveXY (xCoord mouse) 6.2 (rect (-0.4, 0) (0.4, 0.1)))
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 `over` paddle `over` ball 1.5)
animate runs an animation
DS
L F
RP
Zhanyong Wan, 3/27/2002 Yale University 18
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
Zhanyong Wan, 3/27/2002 Yale University 19
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
Zhanyong Wan, 3/27/2002 Yale University 20
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
Zhanyong Wan, 3/27/2002 Yale University 21
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
Zhanyong Wan, 3/27/2002 Yale University 22
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
Zhanyong Wan, 3/27/2002 Yale University 23
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
Zhanyong Wan, 3/27/2002 Yale University 24
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
Zhanyong Wan, 3/27/2002 Yale University 25
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
Zhanyong Wan, 3/27/2002 Yale University 26
Crouching robots, hidden camera
RoboCup
camera
radioradio
Team Bcontroller
Team Acontroller
DS
L F
RP
Zhanyong Wan, 3/27/2002 Yale University 27
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
Zhanyong Wan, 3/27/2002 Yale University 28
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
Zhanyong Wan, 3/27/2002 Yale University 29
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
Zhanyong Wan, 3/27/2002 Yale University 30
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
Zhanyong Wan, 3/27/2002 Yale University 31
SRC in two languages
E-FRPds = 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
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
Zhanyong Wan, 3/27/2002 Yale University 32
SRC in two languages
E-FRPds = 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
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
Zhanyong Wan, 3/27/2002 Yale University 33
SRC in two languages
E-FRPds = 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
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
Plus, E-FRP guarantees resource bound!
DS
L F
RP
Zhanyong Wan, 3/27/2002 Yale University 34
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
Zhanyong Wan, 3/27/2002 Yale University 35
Killer Hovercraft
radars
rocketlaunchers
thrusters
DS
L F
RP
Zhanyong Wan, 3/27/2002 Yale University 36
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
Zhanyong Wan, 3/27/2002 Yale University 37
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