Domain-Specific Languages: Challenges and Opportunities Zhanyong Wan Yale University

DSL FRP Zhanyong Wan, 3/27/2002Yale University2 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!

DSL FRP Zhanyong Wan, 3/27/2002Yale University3 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

DSL FRP Zhanyong Wan, 3/27/2002Yale University4 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

DSL FRP Zhanyong Wan, 3/27/2002Yale University5 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!

DSL FRP Zhanyong Wan, 3/27/2002Yale University6 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!

DSL FRP Zhanyong Wan, 3/27/2002Yale University7 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 manual Peterson, Wan, Hudak, and Nilsson Yale CS-TR, ’01 How do we adapt FRP for systems where response time must be bounded? Real-time FRP Wan, Taha, and Hudak, ICFP ’01 How do we compile FRP to efficient low- level code? Event-driven FRP Wan, Taha, and Hudak, PADL ’02

DSL FRP Zhanyong Wan, 3/27/2002Yale University8 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

DSL FRP Zhanyong Wan, 3/27/2002Yale University9 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 (hybrid) reactive system stimuli responses

DSL FRP Zhanyong Wan, 3/27/2002Yale University10 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 )

DSL FRP Zhanyong Wan, 3/27/2002Yale University11 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

DSL FRP Zhanyong Wan, 3/27/2002Yale University12 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 behaviors f :: a -> b lift f :: Behavior a -> Behavior b Behaviors can react to events b `until` e -=> b’ Backquotes for infix operator

DSL FRP Zhanyong Wan, 3/27/2002Yale University13 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) over combines two animations into one upper, left, right are “still animations” juxtaposition for function application!

DSL FRP Zhanyong Wan, 3/27/2002Yale University14 Paddle ball in four easy steps Step 2. paddle: reacting to mouse 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))) mouse is the position of mouse, a behavior of point moveXY x y a translates animation a by (x, y)

DSL FRP Zhanyong Wan, 3/27/2002Yale University15 Paddle ball in four easy steps Step 3. ball: model of motion 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 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

DSL FRP Zhanyong Wan, 3/27/2002Yale University16 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

DSL FRP Zhanyong Wan, 3/27/2002Yale University17 Paddle ball in four easy steps

DSL FRP Zhanyong Wan, 3/27/2002Yale University18 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

DSL FRP Zhanyong Wan, 3/27/2002Yale University19 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= s 0 t ([b]  d  etc time value

DSL FRP Zhanyong Wan, 3/27/2002Yale University20 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

DSL FRP Zhanyong Wan, 3/27/2002Yale University21 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

DSL FRP Zhanyong Wan, 3/27/2002Yale University22 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)

DSL FRP Zhanyong Wan, 3/27/2002Yale University23 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

DSL FRP Zhanyong Wan, 3/27/2002Yale University24 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; p1 p1  i2 r2; p2 … environ -ment reactive system p i1 environ -ment reactive system p1 r1 environ -ment reactive system p1 i2 environ -ment reactive system p2 r2 p  i r; p’

DSL FRP Zhanyong Wan, 3/27/2002Yale University25 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 v 1 ;p 1, p 1  i2 v 2 ;p 2, …, we have |p k | 0.

DSL FRP Zhanyong Wan, 3/27/2002Yale University26 Crouching robots, hidden camera RoboCup camera radio Team B controller Team A controller

DSL FRP Zhanyong Wan, 3/27/2002Yale University27 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

DSL FRP Zhanyong Wan, 3/27/2002Yale University28 Simple RoboCup Controller (SRC) duty cycle desired speed M IR ClkFastClkSlow IncSpdDecSpd / power behavior event delay SRC count

DSL FRP Zhanyong Wan, 3/27/2002Yale University29 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!

DSL FRP Zhanyong Wan, 3/27/2002Yale University30 SRC in E-FRP Source code ds = 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 duty cycle desired speed power SRC count

DSL FRP Zhanyong Wan, 3/27/2002Yale University31 SRC in two languages E-FRP ds = 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 C init() { 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; } duty cycle desired speed power SRC count

DSL FRP Zhanyong Wan, 3/27/2002Yale University32 SRC in two languages E-FRP ds = 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 C init() { 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; } duty cycle desired speed power SRC count

DSL FRP Zhanyong Wan, 3/27/2002Yale University33 SRC in two languages E-FRP ds = 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 C init() { 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; } duty cycle desired speed power SRC count Plus, E-FRP guarantees resource bound!

DSL FRP Zhanyong Wan, 3/27/2002Yale University34 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!

DSL FRP Zhanyong Wan, 3/27/2002Yale University35 Killer Hovercraft radars rocket launchers thrusters

DSL FRP Zhanyong Wan, 3/27/2002Yale University36 Controlling killer hovercraft in E-FRP fRadar.angle = 0 fRadar.scanWidth = 5 fRadar.maxRange = 10 … -- the same for lRadar and rRadar enemyDir = 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

DSL FRP Zhanyong Wan, 3/27/2002Yale University37 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