issues in domain specific language design and implementation paul hudak dept. of computer science...
Post on 19-Dec-2015
216 views
TRANSCRIPT
Issues in Domain Specific Issues in Domain Specific Language Design and Language Design and
ImplementationImplementation
Paul HudakPaul HudakDept. of Computer ScienceDept. of Computer Science
Yale UniversityYale University
with a tip of the hat to:John Peterson, Zhanyong Wan, and Antony
Courtney (all at Yale), Conal Elliott (Micro$oft Research), Greg Hager (Johns Hopkins Univ.),
and Alastair Reid (Univ. of Utah)Copyright © 2000, Paul Hudak, All rights reserved.
Is “Higher Level” Is “Higher Level” Better?Better?
• A general-purpose programming language is an interface to an abstract machine.
• When is one general-purpose language higher-level than another?
• Assembly language is just the right abstraction for a CPU.
• Why do some languages better match some applications than others?
We Need Domain We Need Domain SpecificitySpecificity
• A domain-specific language (or DSL) is a language that precisely captures a domain semantics; no more, and no less.
• We also need domain specific:– formalizations (starting point!)– optimizations and transformations– software tools– type systems, aspects, constraints, etc.
• Programs in the target domain are:– more concise– quicker to write
– easier to maintain
– easier to reason about
– can often be written by non-programmers
Advantages of DSL Advantages of DSL ApproachApproach
Contribute to higherprogrammer productivity
Dominant cost in large SW systems
Verification, transform- ation, optimization
Helps bridge gap betweendeveloper and user
These are the same arguments in favor of any high-level language! But in addition:
The Bottom LineThe Bottom LineT
ota
l SW
Co
st
C1
C2
Software Life-Cycle
Start-upCosts DSL-based
Methodology
ConventionalMethodology
DSL’s Allow Faster DSL’s Allow Faster PrototypingPrototyping
specify specify
test
design
build test
design
build
With DSLWithout DSL
Using the “Spiral Model” of Software Development
Why Study DSL’s?Why Study DSL’s?• Ok, so DSL’s are useful and important.• But why should we (the POPL community)
be interested in DSL’s?– To have an impact on the real world.– The chances of a general purpose language
succeeding are slim, no matter how good it is.– DSL design and implementation is a source of
new and interesting problems.– It is also fun!
• In the remainder of my talk I will concentrate on the latter two points.
A Case Study: FRPA Case Study: FRP
• Fran is a DSL for functional reactive animation.
• Frob is a DSL for functional robotics.• FRP (functional reactive programming) is the
essence of Fran and Frob:– Fran = FRP + graphics engine + library– Frob = FRP + robot controller + library
• FRP has two key abstractions:– Continuous, time-varying behaviors.– Discrete, reactive events.
A First ExampleA First Example
leftRightCharlotte = moveXY wiggle 0 charlotte
wiggle = sin (pi * time)
charlotte = importBitmap "../Media/charlotte.bmp"
Wiggle vs. WaggleWiggle vs. Waggle
upDownPat = moveXY 0 waggle pat
waggle = cos (pi * time)
pat = importBitmap "../Media/pat.bmp"
The Power of The Power of CompositionComposition
charlottePatDoubleDance = hvDance aSmall aSmall where aSmall = stretch 0.5 charlottePatDance
charlottePatDance = hvDance charlotte pat
hvDance im1 im2 =moveXY wiggle 0 im1 `over` moveXY 0 waggle im2
Stretching with a Stretching with a WiggleWiggle
(and a waggle)
dance2 = hvDance (stretch wiggle charlotte) (stretch waggle pat)
Integrate Twice: Integrate Twice: AccelerationAcceleration
accelBecky = moveXY x 0 becky where x = -1 + integral v v = 0 + integral 1
Mouse Position is a Mouse Position is a BehaviorBehavior
beckyChaseMouse = move offset becky where offset = integral vel vel = mouseMotion - offset
EventsEvents
• Discrete event streams include user input as well as domain-specific sensors, asynchronous messages, interrupts, etc.
• They also include tests for dynamic conditions (“predicate events”) on behaviors (temperature too high, level too low, etc.)
• Operations on event streams include:– Mapping, filtering, reduction, etc.– Reactive behavior modification (next slide).
“Where the Continuous Meets the Discrete”
• FRP’s key reactive form: x `until` e ==> ycan be read:“Behave as x until event e, then behave as y.”
• Declarative semantics.• Rich algebra of transformations.• Examples...
ReactivityReactivity
Reactive Control of Discrete Reactive Control of Discrete ValuesValues
tricycle = withColor (cycle3 green yellow red) (stretch (wiggleRange 0.5 1) circle) where cycle3 c1 c2 c3 = c1 `untilB` lbp ==> cycle3 c2 c3 c1
Reactive Control of Continuous Reactive Control of Continuous ValuesValues
growFlower = stretch size flower where size = 1 + integral bSign
bSign = 0 `until` (lbp ==> -1 `until` lbr ==> bSign) .|. (rbp ==> 1 `until` rbr ==> bSign)
Fran Also Supports 3DFran Also Supports 3D
spiralTurn = turn3 zVector3 (pi*time) (unionGs (map ball [1 .. n])) where n = 40 ball i = withColorG color (move3 motion (stretch3 0.1 sphereLowRes )) where motion = vector3Spherical 1.5 (10*phi) phi phi = pi * fromInt i / fromInt n color = colorHSL (2*phi) 0.5 0.5
A Formal Semantics for A Formal Semantics for FRPFRP
• What should an operational or denotational semantics for FRP look like?
• How is Time represented?• Are all continuous behaviors well-
behaved?• In what sense is an implementation (which
must approximate continuous behaviors) faithful to a formal semantics?
Let’s look first at a denotational semantics.
The Domain of TimeThe Domain of Time
asfollows:Denotethesetofrealnumbersas<,andincludeinthatsettheelements1and¡1.Thissetcomesequippedwiththestandardarithmeticordering·,includingthefactthat¡1·x·1forallx2<.NowdeneTime=<+<,whereelementsinthesec-ond\copy"of<aredistinguishedbyprexingthemwith,asin42,whichshouldberead:\atleast42."Thendene?Time=(¡1),andthedomain(i.e.information)orderingonTimeby:xvx;8x2<xvyifx·y;8x;y2<xvyifx·y;8x;y2<
asfollows:Denotethesetof realnumbersas<, andincludein that
settheelements 1 and¡1 . This setcomesequippedwiththestandardarithmetic ordering· , including thefactthat¡1 · x · 1 for all x 2 <.
Now de¯neTime = < + <, whereelements in the sec-ond \copy" of < are distinguishedby pre¯xingthemwith¸ , as in ¸ 42, which shouldbe read: \at least42." Thende¯ne? Time = ¸ (¡1 ), andthedomain(i.e.information)orderingon Time by:
x v x; 8x 2 <¸ x v y if x · y; 8x;y 2 <¸ x v ¸ y if x · y; 8x;y 2 <
A denotational semantics for Fran requires first a proper treatment of time.
1t
2t
2t
1t
)(
[1,1,1]
[1,1] 1:1:1:_|_
[1] 1:1:_|_
[] 1:_|_
_|_
Infinite list
Analogy between Time and Analogy between Time and ListsLists
Time
Here is arithmetic ordering.
Lists
Here is list-length ordering.
Comparing Partial Comparing Partial ElementsElements
x · ¸ y ´ if x · y thenTrueelse?¸ x · ¸ y ´ ?¸ x · y ´ if x · y then? elseFalse
We can extend the arithmetic ordering to partial elements as follows:
The first line can be read: “The time x is less than or equal to a time that is at least y, if x y, and undefined otherwise.”
Note: is monotonic and continuous.
··
··
··
Semantic FunctionsSemantic Functions
We define two semantic functions, one for behaviors, the other for events:
at : Behavior® ! Time ! ®occ : Event® ! Time £ ®
We will start with the definition of “at”.
Basic ConstructsBasic Constructs
time: BehaviorTimeat[[time]]t = t
liftn : (®1 ! : : : ! ®n ! ¯ ) !Behavior®1 ! : : : ! Behavior®n ! Behavior
at[[liftn f b1 : : :bn ]]t = f (at[[b1]]t) : : : (at[[bn ]]t)
integral : VectorSpace ®) Behavior® ! Time ! Behavior®at[[integral b t0]]t =
Rt
t0at[[b]]
With lift we can re-define most common functions:
etc.primPluslift
primSinlift
2
1
)(
sin
ReactivityReactivity
untilB : Behavior® ! EventBehavior® ! Behavior®at[[buntilB e]]t = if t · te then at[[b]]t else at[[b0]]t
where (te;b0) = occ[[e]]
Note:
• as used here is the extended version defined earlier.
• Transitions occur just after an event happens.
··
The Semantics of The Semantics of EventsEvents
constEv: Time ! ®! Event®occ[[constEvte x]] = (te;x)
predicate: BehaviorBool ! Time ! Event()occ[[predicateb t0]] = (inf f t > t0 j at[[b]]tg; () )
(:j:) : Event® ! Event® ! Event®occ[[e :j: e0]] = (te;x); if te · t0
e= (t0
e;x0); otherwise
where (te;x) = occ[[e]](t0
e;x0) = occ[[e0]]
Note: “Choice” (.|.) is deterministic.
Event Filtering and Event Filtering and SnapshotsSnapshots
(+) ) : Event® ! (Time ! ®! ¯) ! Eventocc[[e +) f ]] = (te; f te x)
where (te;x) = occ[[e]]
(=) ) : Event® ! (®! ¯) ! Event(¤) ) : Event® ! (Time ! ¯) ! Event(¡ ) ) : Event® ! ¯ ! Eventev=) g = ev+) ¸t x: g xev¤) h = ev+) ¸t x: h tev¡ ) x0 = ev+) ¸t x: x0
snapshot: Event® ! Behavior ! Event®£ ¯
occ[[e snapshotb]] = (te; (x; at[[b]]te) )where (te;x) = occ[[e]]
For convenience we also define:
Some Key Design Some Key Design IssuesIssues
• Recursion vs. combinatorsuntil, switch :: Beh a -> Event (Beh a) -> Beh ab `switch` e = b `until` e ==> \b1 -> b1 `switch`
e
• A rich algebra of eventslbp :: Event ( ); key :: Event Char(==>) :: Event a -> (a->b) -> Event baccum :: a -> Event (a -> a) -> Event asnapshot :: Event a -> Behavior b -> Event (a,b)when :: Behavior Bool -> Event ( )(.|.) :: Event a -> Event a -> Event a
• “Aging” the “user”let getString = constB "Init" `switch` accum "" (key ==> \ch -> (++ [ch])) ==>
constBin constB "Start" `switch` lbp -=> getString
Visual LanguagesVisual Languages
• In some domains, the most common notation is pictorial.
• For example: signal processing, digital hardware design, control systems, and sound synthesis.
• Should Fran / FRP be a visual programming language, and if so, what should it look like?
• We need tools to provide both views of a program.
Implementing DSL’sImplementing DSL’s• Language design is difficult!• Idea: Embed DSL in Haskell
(or other language)• Haskell features that facilitate task:
– type classes– higher-order functions– lazy evaluation– syntactic extensions
• Goal: Embed semantics in functions rather than interpret as a data structure.
DSL’s Embedded in DSL’s Embedded in HaskellHaskell
• Graphics/Animation (w/Microsoft)• Robotics (w/JHU)• Computer Vision (Fvision)• Computer Music (Haskore)• Sound Synthesis (Hsound)• Dance/choreography (Haskanotation)
• HaskellScript for the WWW (Utrecht)• Scripting COM objects (Utrecht, Microsoft)• Hardware Description (OGI, Chalmers)• Parsing/pretty printing (Utrecht, Chalmers)• GUI’s (FranTK, etc.)
At Yale:
Elsewhere:
A Typical Fran A Typical Fran ExpressionExpression
1 `until` time>2 -=> time+1
Behavior BehaviorPredicate event
Infix operator Infix operator
This is equivalent to:
until 1 ((-=>)((>) time 2)((+) time 1))
But, what are behaviors and events?
Fran’s BehaviorsFran’s BehaviorsHaskell’s type classes conveniently describe behaviors: newtype Behavior a = Beh (Time -> a) instance Num (Behavior a) where Beh f + Beh g = Beh (\t -> f t + g t) fromInteger x = Beh (\t -> x)
Also define: time = Beh (\t->t)
And thus: 1 Beh (\t->1)
time+1 Beh (\t->t) + Beh (\t->1) Beh (\t-> (\t->t) t + (\t->1) t) Beh (\t-> t+1)
Lazy EvaluationLazy Evaluation
Essential for things like:
color = red `until` lbp ==> blue `until` lbp ==> color
which would not terminate under a call-by-value interpretation.
Lazy evaluation is also used to implement various stream-like objects that represent “demand-driven” computation.
Core Semantics of FranCore Semantics of FranICFP semantics:
at :: Beh a -> Time -> aocc :: Event a -> ((Time,a), Event a)
time :: Beh Timetime `at` t = t
switch :: Beh b -> Event (Beh b) -> Beh b(b `switch` e) `at` t = let ((t0,b0),e0) = occ e in if t<=t0 then b `at` t else (b0 `switch` e0) `at` t
which suggests the implementation:
type Beh a = Time -> atype Event a = [(Time, a)]
b `at` t = b tocc e = (head e, tail e)
User semantics:
at :: Beh a -> (User, Time) -> aocc :: (User, Event a)->((Time,a),User)
time :: Beh Timetime `at` (u,t) = t
switch :: Beh b -> Event(Beh b) ->Beh b(b `switch` e) `at` (u,t) = let ((t0,b0),u0) = occ (u,e) in if t<=t0 then b `at` (u,t) else (b0 `switch` e) `at` (u0,t)
which suggests the implementation:
type Beh a = (User, Time) -> atype Event a = User -> ((Time,a), User)type User = [(Time, UA)]
b `at` (u,t) = b (u,t)occ (u,e) = e u
Time-Ordered SearchTime-Ordered Search• Motivation by analogy:
Consider ordered list L :: [T] and function:inList :: [T] -> T -> Bool
• Now suppose we want to find many elements in L:
manyInList :: [T] -> [T] -> [Bool]manyInList xs ys = map (inList xs) ys
This is quadratic: O(|xs|*|ys|)• Better to order ys first, then do the search:
manyInList xs (y:ys) = let (b,xs’) = inListRem xs yin b : manyInList xs’ ys
This is linear: O(|xs|)
Type-Directed Type-Directed DerivationDerivation
Behaviors:
specification: Beh a = (User, Time) -> auncurry: Beh a = User -> Time -> atime-ordered search: Beh a = User -> [Time] -> [a]unfold User: Beh a = [(UA,Time)] -> [Time] -> [a]unzip User and uncurry: Beh a = [UA] -> [Time] -> [Time]->[a]synchronize: Beh a = [UA] -> [Time] -> [a]
Events:
specification: Ev a = User -> ((Time,a), User)encode non-occurences: Ev a = User -> (Maybe (Time,a), User)decouple aging: Ev a = User -> Maybe (Time,a)time-ordered search: Ev a = User -> [Maybe (Time,a)]unfold User: Ev a = [(UA,Time)] -> [Maybe (Time,a)]unzip User and uncurry: Ev a = [UA] -> [Time] -> [Maybe (Time,a)]synchronize: Ev a = [UA] -> [Time] -> [Maybe a]
Note now: Ev a = Beh (Maybe a)
Advantages of Stream Advantages of Stream DesignDesign
• “User” implicitly “aged;” no User argument to event generators.
• No dynamic adjustments in time; everything is fully synchronized.
• Behaviors can be memoized using a singleton cache.
• Potential for heavy optimization. • Event a = Behavior (Maybe a)
One disadvantage: cannot easily time-transform User.
Faithful Faithful ImplementationsImplementations
• The stream implementation of FRP is an approximation to continuous behaviors.
• But the denotational semantics is exact.• So in what sense is the implementation
faithful to the formal semantics?• Is there any hope for semantics-directed
compilation or transformation/optimization?
Egregious BehaviorsEgregious Behaviors• Consider this behavior:
• This captures Zeno’s Paradox:
and is a natural expression of non-determinism!
time
light off
light onon or off??
1 2
> zeno :: Event ()> zeno = when (lift1 f time) where> f t = if t>2 || t<1 then t<0.5> else f (2*t-2)
More Egregious More Egregious BehaviorBehavior
• Consider this simple behavior:
• This seems innocent enough, but the predicate is true only instantaneously at time = 1. However, a stream-based implementation may miss this event.
• In fact we can show that: A stream-based implementation may miss this event even at the limit of event sampling.
> sharp :: Event ()> sharp = when (time ==* 1)
““Good” BehaviorsGood” Behaviors• Zeno’s paradox represents a problem with the
semantics, and instantaneous events represent a problem with a stream-based implementation.
• Solution: define good behaviors as those that converge to a stable value as the sampling rate increases. Similarly, good events are those whose frequency within a finite period becomes stable as the sampling rate increases.
• Key result: we can show that, with suitable constraints, in the limit, as the sample time increases to infinity, a steam-based implementation is faithful to the denotational semantics.
Domain Specific Domain Specific TransformationsTransformations
• Many domains exhibit nice algebraic properties, with which one can reason about, transform, and optimize programs.
• Query optimization in databases is the prototypical example.
• An implementation can often be proven correct with respect to these properties.
• But we cannot expect a general purpose compiler to perform these optimizations for us.
• We need source level meta-programming tools.
Example: Simple GraphicsExample: Simple Graphics -- Atomic objects: circle -- a unit circle square -- a unit square importGIF "p.gif" -- an imported bit-map
-- Composite objects: scale v p -- scale picture p by vector v color c p -- color picture p with color c trans v p -- translate picture p by vector v p1 `over` p2 -- overlay p1 on p2 p1 `above` p2 -- place p1 above p2 p1 `beside` p2 -- place p1 beside p2
-- Axioms over, above, and beside are associative scale, color, and trans distribute over over, above, & beside scale is multiplicative, trans is additive etc.
Thus an algebra of graphics emerges.
Simple AnimationsSimple Animations type Behavior a = Time -> a type Animation = Behavior Picture
Now we “lift” the simple graphics operations to work on behaviors as well. For example:
(b1 `overB` b2) t = b1 t `over` b2 t (b1 `aboveB` b2) t = b1 t `above` b2 t (b1 `besideB` b2) t = b1 t `beside` b2 t
(scaleB v b) t = scale (v t) (b t) (colorB c b) t = color (c t) (b t) (transB v b) t = trans (v t) (b t)
And a new function to express the current time:
time t = t
All previous graphics axioms hold for animations.
Basic Haskore DesignBasic Haskore Designtype Pitch = (PitchClass, Octave)data PitchClass = Cf | C | Cs | Df | D | Ds | Ef | E | Es | Ff | F | Fs | Gf | G | Gs | Af | A | As | Bf | B | Bstype Octave = Int
data Music = Note Pitch Dur -- a note \ atomic | Rest Dur -- a rest / objects | Music :+: Music -- sequential composition | Music :=: Music -- parallel composition | Tempo Int Int Music -- scale the tempo | Trans Int Music -- transposition | Instr IName Music -- instrument label
type Dur = Float -- in whole notestype IName = Stringtype PName = String
Performance & Performance & InterpretationInterpretation
A performance is a temporal sequence of musical events.
type Performance = [Event]data Event = Event Time IName AbsPitch DurT Volume
type Time = Floattype DurT = Floattype Volume = Float
Now we need a way to perform (I.e. interpret) music.
perform :: Context -> Music -> Performancetype Context = (Time,IName,DurT,Key,Volume)
perform
time instrument tempo key volume
Music Performance
Literal InterpretationLiteral Interpretation
A literal interpretation is the most straightforward. perform c@(t,pl,i,dt,k,v) m = case m of Note p d -> playNote pl c p d Rest d -> [] m1 :+: m2 -> perform c m1 ++ perform (setTime c (t+(dur m1)*dt)) m2 m1 :=: m2 -> merge (perform c m1) (perform c m2) Tempo a b m -> perform (setTempo c (dt * float b / float a)) m Trans p m -> perform (setTrans c (k+p)) m Instr nm m -> perform (setInstr c nm ) m Player nm m -> perform (setPlayer c (pmap nm)) m Phrase pas m -> interpPhrase pl c pas m
Equivalence of Musical Equivalence of Musical ObjectsObjects
Two musical objects are (observationally) equivalent if they result in the same literal performance under all contexts.
Definition: m1 = m2 iff for all contexts con, perform con m1 = perform con m2
An Algebra of Music An Algebra of Music EmergesEmerges
Using simple equational reasoning, many useful axiomsare easily proven:
• Tempo-scaling is multiplicative.• Transposition is additive.• Parallel composition is commutative.• Tempo-scaling and transposition are distributive over both sequential and parallel composition.• Sequential and parallel composition are associative.• Rest 0 is a unit for Tempo and Trans, and a zero for sequential and parallel composition.
MotivationMotivation
• Mobile robot control is hard!• Prototyping is essential: repeated experimentation
required.• Must deal with unpredictability: imprecise sensors,
uncertain environment, mechanical problems. • Need to compose solved sub-problems.• Reliability needed - programs must recover from
errors; explore alternative strategies to meet goals.
Our Solution: FrobOur Solution: Frob
• Recall that:Frob = FRP + robot controller + robot/vision library
• Programming robots is a lot like programming an animation!
• … except that:– The robot doesn’t always do what you want it to
do.– Error / anomalous conditions are more common.– Real-time issues are more dominant.– Robots are a lot slower than graphics hardware.
Our Robots:
Nomadic Technologies SuperScoutNomadic Technologies SuperScout
Computing: PC running Linux Hugs Radio Modem
Vision16 SonarsBumpers
WheelControls
A Control System for Wall FollowingA Control System for Wall Following
Front Sonar
Side Sonar
Objectives: Maintain a specified distance from wall
Don’t turn too much toward wall
Stop (slowly) when approaching an obstacle ahead.
= limit(max, f - d)= limitsinmax * curr, s - d) - ds/dtlimit(mx,v) = max(-mx,min(v,mx))
s
f
follow f s d = (v,w) where v = limit vmax (f-d) w = limit (vcurr * sin amax) (s-d) - derivative s
Time is Implicit!Notation is nearly identical.Details of clocking are hidden.
Adding ReactivityAdding Reactivity
type Wheels = (SpeedB, AngleB)wfollow :: SonarB -> SonarB -> FloatB -> (WallEnd -> Wheels) -> Wheels wfollow f s d c = follower f s d `untilB` ( predicate (f <= d) -=> Blocked .|. predicate (s >= 2*d) -=> NoWall) ==> c
Wall follower terminates two ways:
-- Blocked in front -- No wall on side
The behaviorThe terminating eventThe continuation of the overall behaviorCapture this pattern in a Monad!
Data WallEnd = Blocked | NoWall
A Task MonadA Task MonadA task couples a behavior with a termination event. In it’s simplest form, we combine a behavior and an event into a task:
mkTask :: (Behavior a, Event b) -> Task a b
Continuous value defined by task
Value returned at end of task
(b1,e1) >> (b2,e2) = (b1 `untilB` e1 -=> b2, e2)
Hide reactivity inside monadic sequencing
Using TasksUsing TaskswallTask f s d = mkTask (wallFollow f s d, predicate (f <= d) -=> Blocked .|. predicate (s >= 2*d) -=> NoWall)
roomFollow f s d = do status <- wallTask f s d case status of NoWall -> turnLeft Blocked -> turnRight roomFollow f s dTurn
Left
No Wall
Wallleft
WallFollowLeft
Turn Right
Blocked
Free
What’s under the hood?What’s under the hood?
Event based interface to the outside worldSmoothing / sampling to allow continuous representationsClocking controls for smoothing / sampling.
Dispatch outputevents
Accept inputevents
Samplingand
Smoothing User Program
FRP Gateway Clocking Policy “Mostly” continuousworld
ConclusionsConclusions
• Domain Specific Languages are a Good Thing.• Embedded DSL’s (ala Haskell) can be used to implement highly effective programming environments.• “Functional Reactive Programming” is a good abstraction for many real-time reactive domains.• The programming languages community has some good ideas; let’s start using them!• DSL technology is fertile ground for programming language research.
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
---C.A.R. Hoare
GloveGlove
by Tom Makucevichby Tom Makucevich
with help from Paul Hudakwith help from Paul Hudak
Composed using Haskore, a Haskell DSL,Composed using Haskore, a Haskell DSL,and rendered using csound.and rendered using csound.
For Further Reading...For Further Reading...
• The Haskell School of Expression -- Learning Functional Programming through Multimedia
• Cambridge University Press• Teaches functional programming using
Haskell, including three DSL’s: a Fran-like language (FAL), a Haskore-like language (MDL), and an imperative robot language (IRL).
• Available now from amazon.com, bn.com, etc.
Ongoing WorkOngoing Work
• Vision-based Control (via FVision, another Haskell DSL)
• Planning / Scheduling / Multiple robots• Teach Haskell & robotics to students• Better implementation / optimization• Better tools (debugging, profiling, etc.)• Formal semantics / verification• Hybrid / control systems