Modelling Time in Computation (Dynamic Systems)

Abstract
Functional Reactive Programming
for Real-Time Reactive Systems
Zhanyong Wan
2002
A real-time reactive system continuously reacts to stimuli from the environment by send-
ing out responses, where each reaction must be made within certain time bound. As
computers are used more often to control all kinds of devices, such systems are gaining
popularity rapidly. However, the programming tools for them lag behind.
In this thesis we present RT-FRP, a language for real-time reactive systems. RT-FRP can
be executed with guaranteed resource bounds, and improves on previous languages for
the same domain by allowing a restricted form of recursive switching, which is a source
of both expressiveness and computational cost. The balance between cost guarantee and
expressiveness is achieved with a carefully designed syntax and type system.
To better suit hybrid systems and event-driven systems, we have designed two vari-
ants of RT-FRP called H-FRP and E-FRP respectively. We give H-FRP a continuous-time
semantics natural for modeling hybrid systems and an operational semantics suitable for
a discrete implementation. We show that under certain conditions the operational seman-
tics converges to the continuous-time semantics as the sampling interval approaches zero.
We also present a provably correct compiler for E-FRP, and use E-FRP to program both
real and simulated robots.

Functional Reactive Programming
for Real-Time Reactive Systems
A Dissertation
Presented to the Faculty of the Graduate School
of
Yale University
in Candidacy for the Degree of
Doctor of Philosophy
by
Zhanyong Wan
Dissertation Director: Professor Paul Hudak
December 2002

Copyright c2003 by Zhanyong Wan
All rights reserved.
ii

Contents
Acknowledgments viii
Notations ix
1 Introduction 1
1.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 General-purpose languages . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Synchronous data-ﬂow reactive languages . . . . . . . . . . . . . . . 4
1.2.3 FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Advice to the reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 A base language 14
2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Type system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Type language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.2 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.3 Typing judgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
i

2.3 Operational semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Properties of BL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 Real-Time FRP 30
3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Operational semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1 Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.2 Two judgment forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.3 The mechanics of evaluating and updating . . . . . . . . . . . . . . . 37
3.3 Two kinds of recursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.2 Cycles in a state transition diagram . . . . . . . . . . . . . . . . . . . 42
3.3.3 Recursion in FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4 Type system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.1 What can go wrong? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4.2 Typing rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.3 How it comes about . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5 Resource bound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.5.1 Type preservation and termination . . . . . . . . . . . . . . . . . . . . 52
3.5.2 Resource boundedness . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.5.3 Space and time complexity of terms . . . . . . . . . . . . . . . . . . . 56
3.6 Expressiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6.1 Encoding ﬁnite automata . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.6.2 Example: a cruise control system . . . . . . . . . . . . . . . . . . . . . 62
3.7 Syntactic sugar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.7.1 Lifting operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.7.2 Some stateful constructs . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.7.3 Pattern matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
ii

3.7.4 Mutually recursive signals . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.7.5 Repeated switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.7.6 Optional bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.7.7 Direct use of signal variables . . . . . . . . . . . . . . . . . . . . . . . 70
3.7.8 Local definitions in the base language . . . . . . . . . . . . . . . . . . 71
4 Hybrid FRP 73
4.1 Introduction and syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2 Type system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2.1 Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2.2 Typing judgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3 Denotational semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.3.1 Semantic functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3.2 Environment-context compatibility . . . . . . . . . . . . . . . . . . . 82
4.3.3 Definition of at and occ . . . . . . . . . . . . . . . . . . . . . . 83
4.4 Operational semantics via translation to RT-FRP . . . . . . . . . . . . . . . . 86
4.5 Convergence of semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.5.1 Definitions and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.5.2 Establishing the convergence property . . . . . . . . . . . . . . . . . . 101
4.6 Applications of H-FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5 Event-driven FRP 108
5.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.1.1 Physical model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.1.2 The Simple RoboCup (SRC) controller . . . . . . . . . . . . . . . . . . 111
5.1.3 Programming SRC with event handlers . . . . . . . . . . . . . . . . . 113
5.2 The E-FRP language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.2.1 Execution model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
iii

5.2.3 Type system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.2.4 Operational semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.2.5 SRC in E-FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.3 SimpleC: an imperative language . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.3.2 Compatible environments . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.3.3 Operational semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.3.4 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.4 Compilation from E-FRP to SimpleC . . . . . . . . . . . . . . . . . . . . . . . 130
5.4.1 Compilation strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.4.2 Compilation examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.4.3 Correctness of compilation . . . . . . . . . . . . . . . . . . . . . . . . 133
5.4.4 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.5 Translation from E-FRP to RT-FRP . . . . . . . . . . . . . . . . . . . . . . . . 141
5.6 Application in games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.6.1 An introduction to MindRover . . . . . . . . . . . . . . . . . . . . . . 143
5.6.2 Programming vehicles in MindRover . . . . . . . . . . . . . . . . . . 144
5.6.3 From E-FRP to ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.6.4 The KillerHover example . . . . . . . . . . . . . . . . . . . . . . . . . 148
5.7 Discussion on later . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.7.1 delay of RT-FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.7.2 A better delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.7.3 later as syntactic sugar . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6 Related work, future work, and conclusions 155
6.1 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.1.1 Hybrid automata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.1.2 FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
iv

6.1.3 Synchronous data-ﬂow languages . . . . . . . . . . . . . . . . . . . . 157
6.1.4 SAFL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.1.5 Multi-stage programming . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.1.6 SCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
6.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
6.2.1 Clocked events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
6.2.2 Arrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
6.2.3 Better models for real-time systems . . . . . . . . . . . . . . . . . . . 163
6.2.4 Parallel execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
6.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
A Proof of theorems 165
A.1 Theorems in Chapter 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Bibliography 199
v

List of Figures
1.1 The RT-FRP family of languages and their domains . . . . . . . . . . . . . . 10
2.1 Syntax of BL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Type language of BL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Type system of BL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Operational semantics of BL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Syntax of RT-FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Operational semantics for RT-FRP: evaluation rules . . . . . . . . . . . . . . 37
3.3 Operational semantics for RT-FRP: updating rules . . . . . . . . . . . . . . . 38
3.4 Type system for RT-FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1 Syntax of H-FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2 Type system of H-FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.3 Denotational semantics of behaviors . . . . . . . . . . . . . . . . . . . . . . . 84
4.4 Denotational semantics of events . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.5 Semantics of when: no occurrence . . . . . . . . . . . . . . . . . . . . . . . . 87
4.6 Semantics of when: occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.7 Semantics of when: not enough information . . . . . . . . . . . . . . . . . . 89
4.8 Translation from H-FRP to RT-FRP . . . . . . . . . . . . . . . . . . . . . . . . 91
5.1 Simple RoboCup Controller: block diagram . . . . . . . . . . . . . . . . . . . 112
5.2 The SRC controller in C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
vi

5.3 Syntax of E-FRP and deﬁnition of free variables . . . . . . . . . . . . . . . . 118
5.4 Type system of E-FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.5 Operational semantics of E-FRP . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.6 The SRC controller in E-FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.7 Syntax of SimpleC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.8 Operational semantics of SimpleC . . . . . . . . . . . . . . . . . . . . . . . . 127
5.9 Compilation of E-FRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.10 The SRC controller in SimpleC . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.11 Optimization of the target code . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.12 Optimization of the SRC controller . . . . . . . . . . . . . . . . . . . . . . . . 140
5.13 Structure of the Killer Hovercraft . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.14 E-FRP program for the Killer Hovercraft . . . . . . . . . . . . . . . . . . . . . 150
vii

Acknowledgments
First, I would like to thank my adviser, Paul Hudak, for his guidance and encouragement.
Without his persistence and patience, I could not have made it through my Ph.D. program.
Special thanks to Walid Taha for his kind direction. This work owes much to his help
even though he is not officially on my reading committee.
Many thanks to John Peterson for interesting discussions and insightful comments,
and for constantly bugging me to go outdoors (thus keeping me alive through out my
years at Yale).
Thanks to Zhong Shao for inspiration. Thanks to Conal Elliott for his early work on
Fran, which has been the basis of my work.
This work has benefited from discussions with Henrik Nilsson, Antony Courtney, and
Valery Trifonov.
Finally, I want to thank my family for their understanding and sacrifice.
viii

Notations
Common:
Ü Ý Ü and Ý are semantically equal
Ü Ý Ü and Ý are syntactically identical
Æ set of natural numbers, ½ ¾ ¡¡¡
ÆÒ set of the ﬁrst Ò natural numbers, ½ ¾ ¡¡¡ Ò
(for all Ò ¼, we deﬁne ÆÒ to be the empty set)
Ê set of real numbers
Ì set of times (non-negative real numbers, Ø ¾Ê
¬
¬ Ø ¼ )
function from to
Ô function mapping bound pattern Ô to formula
empty set,
closed interval, Ü ¾Ê
¬
¬ Ü
´ µ open interval, Ü ¾Ê
¬
¬ Ü
Ö absolute value of real number Ö
Î ´ µ set of free variables in term
Ü substitution of all free occurrences of Ü for in
Ñ Ò set of integers between Ñ and Ò,
¬
¬ Ñ Ò
Ñ Ò sequence of integers from Ñ to Ò, Ñ Ñ · ½ ¡¡¡ Ò
¾Ë set of formulas where is drawn from set Ë
¾Ë sequence of formulas where is drawn from sequence Ë
ix

½ ¾ ¡¡¡ Ò set of formulas
½ ¾ ¡¡¡ Ò sequence of formulas
set of formulas
sequence of formulas
empty term
assuming that
·· concatenation of sequences and
wildcard variable
µ implies
the type “sequence of ”
bottom
lifted set ,
Ú Ú¼ difference between Ú and Ú¼
For the BL language:
´µ unit element or unit type
´ ½ ¾ ¡¡¡ Òµ Ò-tuple1, where Ò ¾
Maybe « option type whose values are either Nothing or Just Ú,
where Ú has type «
True synonym for Just ´µ
False synonym for Nothing
½ ¡¡¡ Ò « «¼ ½ ¡¡¡ Ò are functions from « to «¼
variable context
´Üµ « context assigns type « to Ü
¨ Ü « context identical to except that Ü is assigned type «
« term has type « in context
1
The notation of a 2-tuple is the same as an open interval, but the context always makes the intended
meaning clear.
x

Ú ¾« value Ú has type « in the empty context, Ú «
Ú ¸ Ú¼ applying function to value Ú yields Ú¼
variable environment
set of all variable environments
´Üµ Ú environment maps Ü to Ú
¨ Ü Ú environment identical to except that Ü maps to Ú
variable environment is compatible with variable context
¸ Ú evaluates to Ú in environment
For the RT-FRP language:
¢ variable context
¡ signal context
signal environment
¢ ¡ S × « × is a signal of type « in contexts ¢, and ¡
¢ ¡ signal environment is compatible with contexts , ¢, and ¡
×
Ø
¸ Ú × evaluates to Ú on input at time Ø, in environment
×
Ø
×¼ × is updated to become ×¼ on input at time Ø, in environment
and
×
Ø
¸ Ú ×¼ shorthand for ×
Ø
¸ Ú and ×
Ø
×¼
×
Ø
¸ Ú ×¼ shorthand for ×
Ø
¸ Ú ×¼
× size of signal ×
size bound of signals in
× Ñ size bound of signal ×
For the H-FRP language:
ª behavior context
behavior environment
xi

set of all behavior environments
Ú optional value, Ú or
lifted variable environment, which maps variables to
optional values
set of all lifted variable environment
ª behavior environment is compatible with behavior
contexts ª
ª B « is a behavior of type « in context and ¡
ª Ú E « Ú is an event of type « in context and ¡
tr translation of H-FRP term to RT-FRP
eval value of in environment
ÈØ time sequence whose last element is Ø
È norm of time sequence È
È Ø¼
norm of time sequence È with respect to start time Ø¼
Ú ¯ ¯-neighborhood of value Ú, Ü
¬
¬ Ü Ú ¯
Ë ¯ ¯-neighborhood of set Ë, ¦Ú¾Ë Ú ¯
Ø Ð Ø¼ shorthand for either Ø Ø¼ or Ø Ø¼ ¼
TS set of time sequences, Ø½ ¡¡¡ ØÒ
¬
¬ Ò ¾Æ and Ø½ ¡¡¡ ØÒ
¡Ø shorthand for Ø ·½ Ø
at continuous semantics of behavior in environment
at discrete semantics of behavior in environment
at
£
limit of discrete semantics of behavior in environment
occ Ú continuous semantics of event Ú in environment
occ Ú discrete semantics of event Ú in environment
occ
£ Ú limit of discrete semantics of event Ú in environment
For the E-FRP language:
xii

··
¼ concatenation of sequences and ¼
Î ´ µ set of free variables in
« is a behavior of type « in context
È assigns types to behaviors in È
È Á
¶ Ú on event Á, behavior yields Ú
È Á
· ¼ on event Á, behavior is updated to ¼
È Á
Ú ¼ shorthand for È Á
¶ Ú and È Á
· ¼
È
Á
È¼ on event Á, program È yields environment and is updated
to È¼
assignment sequence is compatible with
environment and assignment sequence are compatible with
É environment and SimpleC program É are compatible with
¸ ¼ executing assignment sequence updates environment to ¼
É
Á
¸ ¼ ¼¼ when event Á occurs, program É updates environment to ¼
in the ﬁrst phase, then to ¼¼ in the second phase
Ü does not depend on Ü or any variable updated in
È ½
Á is the ﬁrst phase of È’s event handler for Á
È ¾
Á is the second phase of È’s event handler for Á
È É È compiles to É
ÊÎ ´ µ set of right-hand-side variables in assignments
ÊÎ ´Éµ set of right-hand-side variables in program É
ÄÎ ´ µ set of left-hand-side variables in assignments
È É µÉ¼ È compiles to É, and then is optimized to É¼
environment restricted to variables in set ,
Ü ´Üµ
¬
¬ Ü ¾ ÓÑ´ µ
xiii

Chapter 1
Introduction
1.1 Problem
According to Berry [5], computerized systems can be divided into three broad categories:
¯ transformational systems that compute output from inputs and then stop, examples
including numerical computation and compilers,
¯ interactive systems that interact with their environments at a pace dictated by the
computer systems, and
¯ reactive systems that continuously react to stimuli coming from their environment by
sending back responses.
The main difference between an interactive system and a reactive system is that the
latter is purely input-driven and must react at a pace dictated by the environment. Ex-
amples of reactive systems include signal processors, digital controllers, and interactive
computer animation. A reactive system is said to be real-time if the responses must be
made within a certain time bound or the system will fail. Today, many real-time reactive
systems are being designed, implemented, and maintained, including aircraft engines,
military robots, smart weapons, and many electronic gadgets. As this trend continues,
1

the reliability and safety of programming languages for such systems become more of a
concern.
In our context, we call the sequences of time-stamped input, output, and intermediate,
values in a reactive system signals. A signal can be viewed as the trace of a value that
potentially changes with each reaction. Operations in a reactive system are often easier
described as being performed on signals rather than on static values. For example, instead
of updating the value of a variable, we often want to change the behavior of a whole
signal; instead of adding two static values, we may need to add two signals pointwise.
There are also some temporal operations that only make sense for signals, like integrating
a numeric signal over time.
Programming real-time reactive systems presents some challenges atypical in the de-
velopment of other systems:
1. Reactive systems emphasize signals rather than static values. Hence the program-
ming languages should directly support the representation of signals and operations
on them. As a signal is a potentially inﬁnite sequence of time-stamped values, it can-
not be directly represented in ﬁnite space, and thus requires special techniques.
2. Since the system has to respond to the environment fast enough to satisfy the real-
time constraint, it is important to know at compile time the maximum amount of
space and time a program might use to make a response.
3. Some reactive systems are hybrid, in the sense that they employ both components
that work in discrete steps (e.g. event generators and digital computers) and compo-
nents that work continuously (e.g. speedometers and numerical integrators). Con-
tinuous components must be turned into some form that can be handled by digital
computers, for example using symbolic computation or by sampling techniques.
4. Furthermore, many such systems run on computers with limited space and com-
putational power (e.g. embedded systems and digital signal processors), and hence
2

efﬁciency is a major concern.
1.2 Background
While programming languages and tools for transformational systems and interactive
systems have been relatively well-studied, those for reactive systems have not been prop-
erly developed for historical reasons [5]. This section summarizes some previous attempts
to program reactive systems.
1.2.1 General-purpose languages
Traditionally, reactive systems have been programmed using general-purpose imperative
languages, C being a typical example. Unfortunately, this approach has some severe lim-
itations:
¯ As the programming language lacks the ability to operate on signals as a whole,
the programmer has to deal with snapshots of signals instead. Hence, a variable
is allocated to hold the snapshot of a signal, and the program is responsible for
updating this variable, possibly with each reaction. Great care must be taken by the
programmer to ensure that a variable is referenced and updated at the right time,
because the same variable is reused to hold different elements in a value sequence.
Such low-level details make programming both tedious and error-prone.
¯ To complicate things even more, a dynamic reactive system may create or destroy
signals at run time. When this happens, not only the memory associated with the
signals needs to be allocated or reclaimed, the program also needs to know how
to update the new signals with each reaction, and cease updating the dead signals.
Again, the language provides no special support for this.
¯ As signals are not ﬁrst-class in a general-purpose language, they cannot be stored
in data structures or passed as function arguments or results, making programming
3

complex systems even more difficult.
¯ Finally, as the programming language is not designed with resource bounds in
mind, it is usually difficult to analyze the space and time needed to make a reaction,
not to mention guaranteed resource bounds. The reliability of real-time systems is
thus compromised.
In summary, this approach provides the lowest level of abstraction and the least guar-
antee on resource consumption. Although the learning curve of this approach is the least
steep for an ordinary programmer, development and maintenance cost is usually high
while the software productivity and reliability are low. Hence general-purpose languages
are not recommended except for trivial reactive systems.
1.2.2 Synchronous data-flow reactive languages
In a reactive system, signals may have different values depending on when they are ob-
served. Hence we say “the value of expression at time Ø” rather than simply “the value
of expression .” Consider the case where we need to calculate the value of some expres-
sion ½ · ¾ at time Ø. We can do this by calculating first ½, then ¾, and then adding the
results. Depending on how we treat time, there are two options:
1. We compute in real time: At time Ø, ½ is evaluated. By the time this computation
finishes, time has advanced to Ø¼ Ø. We then evaluate ¾ at this later time Ø¼. The
final result will be the sum of the value of ½ at Ø and the value of ¾ at Ø¼. Clearly, as
expressions get more complex, the meaning of them becomes increasingly dubious,
and it is very hard to reason about a program or to perform optimizations.
2. Alternatively, we can assume that computations have zero duration. In other words,
we “freeze” the logical time until the computation for one reaction step is done. In
this framework, we will get the sum of the value of ½ at Ø and the value of ¾ at
Ø. This semantics is much easier to understand and work with, and is acceptable if
computations can be shown to have bounded effective duration.
4

The second approach above is called a synchronous view on reactive systems.
In general, the value of a signal at time Ø may depend on the values of other signals
at time Ø and/or the values of all signals before Ø (causality precludes it to depend on
the value of some signal after Ø). However, a system is unimplementable if it requires
remembering an unbounded length of history. For example, in the reactive system defined
by
Ö × ¾
where × is the -th stimulus and Ö is the -th response, we need to know the ¾ -
th input as we are generating the -th response. What’s more, in order to be able to
generate future responses, we need to remember the ´ ¾ · ½µ-th to the -th stimuli as
well. As time advances, the buffer grows without bound. Hence this system cannot be
implemented, at least with finite storage.
In our context, the word synchrony also means there is no need for an unbounded
buffer to hold the history of signals. Hence the above system is not synchronous. As an
example of synchronous systems, the Fibonacci sequence can be defined by
¼ ½
½ ½
·¾ · ·½
which only needs a buffer to hold two previous values.
In the last two decades, several synchronous data-flow reactive programming languages,
including SIGNAL[18], LUSTRE[7], and ESTEREL[5], have been proposed to develop re-
active systems more easily and more reliably. Languages in this category assume that
computations have zero duration and only bounded history is needed (hence the word
“synchronous”), and manipulate signals as a whole rather than as individual snapshots
(hence the name “data-flow”).
5

These languages capture the synchronous characteristics of reactive systems, treat sig-
nals as first-class citizens, and thus are a vast improvement over general-purpose lan-
guages. However, in order to guarantee resource bounds, they allocate memory statically
and are hence not flexible enough to naturally express systems that change functionalities
at run time and thus need to allocate memory dynamically. Besides, they are built on the
basis that time advances in discrete steps, and thus fail to provide adequate abstraction
for continuous quantities.
1.2.3 FRP
Our work has been inspired by Functional Reactive Programming (FRP) [25, 53], a high-
level declarative language for hybrid reactive systems. FRP was developed based on ideas
from Elliott and Hudak’s computer animation language Fran [15, 16]. It classifies signals
into two categories: behaviors (values that continuously change over time) and events (val-
ues that are present only at discrete time points). The concept of a behavior is especially
fitting for modeling a signal produced by a continuous component. Both behaviors and
events are first-class, and a rich set of operations on them (including integration of nu-
meric behaviors over time) are provided. An FRP program is a set of mutually recursive
behaviors and events.
FRP has been used successfully in domains such as interactive computer animation
[16], graphical user interface design [11], computer vision [44], robotics [42], and control
systems [55], and is particularly suitable for hybrid systems. FRP is sufficiently high-level
that, for many systems, FRP programs closely resemble equations naturally written by
domain experts to specify the problems. For example, in the domain of control systems,
a traditional mathematical specification of a controller can be transformed into running
FRP code in a matter of minutes.
FRP is implemented as an embedded language [14, 24] in Haskell [17], and provides
no guarantees on execution time or space: programs can diverge, consume large amounts
6

of space, and introduce unpredictable delays in responding to external stimuli. The re-
sponsibility of ensuring resource bounds lies on the programmer. In many applications
FRP programs have been “fast enough,” but for real-time applications, careful program-
ming and informal reasoning is the best that one can do.
1.3 Goal
A good programming language for a certain problem domain should capture the essence
of that domain and provide the right level of abstraction. Programs written in such a
language should be close to the high-level specification of the problem. In particular, the
programmer should not be concerned with implementation details that can be handled by
the compiler, while at the same time he should be able to be specific about things he cares
about. In the case of real-time reactive systems, this means the language should support
the manipulation of signals naturally, provide formal assurance on resource bounds, and
yield efficient programs.
This thesis presents our effort in developing such a language for real-time reactive
systems. We call it RT-FRP for Real-Time Functional Reactive Programming [54]. We try
to make the language simple for presentation purpose, yet interesting enough to convey
all of our design ideas.
1.4 Approach
We call our language Real-Time FRP since it is roughly a subset of FRP. In RT-FRP there
is one global clock, and the state of the whole program is updated when this clock ticks.
Hence every part of the program is executed at the same frequency. By their very nature,
RT-FRP programs do not terminate: they continuously emit values and interact with the
environment. Thus it is appropriate to model RT-FRP program execution as an infinite
sequence of steps. In each step, the current time and current stimuli are read, and the pro-
7

gram calculates an output value and updates its state. Our goal is to guarantee that every
step executes in bounded time, and that overall program execution occurs in bounded
space. We achieve this goal as follows:
1. Unlike FRP, which is embedded in Haskell, RT-FRP is designed to be a closed lan-
guage [31]. This makes it possible to give a direct operational semantics to the lan-
guage.
2. RT-FRP’s operational semantics provides a well-defined and tractable notion of cost.
That is, the size of the derivation for the judgment(s) defining a step of execution
provides a measure of the amount of time and space needed to execute that step on
a digital computer.
3. Recursion is a great source of expressiveness, but also of computational cost. A key
contribution of our work is a restricted form of recursion in RT-FRP that limits both
the time and space needed to execute such computations. We achieve this by first
distinguishing two different kinds of recursion in FRP: one for feedback, and one
for switching. Without constraint, the first form of recursion can lead to programs
getting stuck, and the second form can cause terms to grow arbitrarily in size. We
address these problems using carefully chosen syntax and a carefully designed type
system. Our restrictions on recursive switching are inspired by tail-recursion [43].
4. We define a function on well-typed programs that determines an upper bound
on the space and time resources consumed when executing a program. We prove
that × Ç´¾
´size of ×µµ for a well-typed program ×.
5. A key aspect of our approach is to split RT-FRP into two naturally distinguishable
parts: a reactive language and a base language. Roughly speaking, the reactive lan-
guage is comparable to a synchronous system [8], and the base language can be any
resource-bounded pure language that we wish to extend to a reactive setting. We
show that the reactive language is bounded in terms of both time and space, inde-
8

pendent of the base language. Thus we can reuse our approach with a new base
language without having to re-establish these results. Real-time properties of the
base language can be established independently, and such techniques already exist
even for a functional base language [23, 28, 29, 36].
6. The operational semantics of RT-FRP can be used to guide its implementation, and
we have developed an interpreter for RT-FRP in the Haskell language [26].
As with any engineering effort, the design of RT-FRP is about striking a balance be-
tween conflicting goals. In this case, we strive to make the language expressive yet re-
source bounded. On one end of the design spectrum we have FRP, which has full access to
-calculus and therefore is by no means resource bounded; on the other end we have stat-
ically allocated languages like LUSTRE and ESTEREL, in which all necessary space has to
be allocated at compile time. RT-FRP sits somewhere in the middle: it allows a restricted
form of recursive switching, which incurs dynamic memory allocation, yet guarantees
that programs only use bounded space and time.
However, like other synchronous data-flow languages, RT-FRP is based on the notion
that time is discrete. While this is adequate for modeling systems where all components
change states at discrete points in time, it is unnatural for hybrid reactive systems, which
employ components that change continuously over time. For such systems, we developed
a variant of RT-FRP called Hybrid FRP (H-FRP), in which we have both continuous-time-
varying behaviors and discrete-time-occurring events.
In H-FRP, the best intuition for a behavior is a function from real-valued times. Such
a function is defined at all times, and is free to change at any time. Hence, an H-FRP pro-
gram is best modeled by a continuous-time-based denotational semantics. This semantics,
although being handy for reasoning about the program, cannot be directly implemented
on a digital computer, which by its very nature can only work discretely. Therefore we
also define an operational semantics to guide a discrete implementation.
9

An interesting problem is that as the operational semantics works in discrete steps and
thus is only an approximation to the continuous model, its result does not always match
that given by the denotational semantics, although we expect them to be close. One of
our major contribution is that, assuming that we can represent real numbers and carry
out operations on them exactly, we prove that under suitable conditions the operational
semantics converges to the continuous-time semantics as the sampling intervals approach
zero, and we identify a set of such conditions. We should point out that in order to have
this convergence property, H-FRP has to be more restricted than RT-FRP.
Some reactive systems are purely driven by events, where the system does not change
unless an event occurs. In using RT-FRP for such event-driven systems, we found that the
compiler can generate much more efﬁcient code if we impose certain restrictions on the
source program. We formalize these restrictions and call the restricted language Event-
driven FRP (E-FRP) [55]. A compiler for E-FRP is deﬁned and proved to be correct. While
our use of RT-FRP and H-FRP is still experimental, we have successfully used E-FRP
to program low-level controllers for soccer-playing robots and controllers for simulated
robotic vehicles in the MindRover computer game [45].
RT-FRPH-FRP E-FRP
real-time
reactive systems
hybrid
systems
event-driven
systems
Figure 1.1: The RT-FRP family of languages and their domains
10

H-FRP and E-FRP are roughly subsets of RT-FRP (in fact, we give translations that turn
H-FRP and E-FRP programs into RT-FRP). The hierarchy of the three languages and their
corresponding domains are illustrated in Figure 1.1. An interesting observation is that
the hierarchical relationship between the languages corresponds to that of the problem
domains. This confirms our belief that nested domains call for nested domain-specific
languages.
1.5 Contributions
Our contributions are fourfold: first, we have designed a new language RT-FRP and its
two variants (H-FRP and E-FRP) that improve on previous languages; second, we have
proved the resource bound property of programs written in RT-FRP; third, we have es-
tablished the convergence property of H-FRP programs; and fourth, we have presented a
provably-correct compiler for E-FRP.
More specifically, our contributions toward language design are: a modular way of
designing a reactive language by splitting it into a base language and a reactive language
(Chapter 2); and a type system that restricts recursion such that only bounded space can be
consumed (Chapter 3). Our contributions toward semantics are: a continuous-time-based
denotational semantics for H-FRP; and the identification of a set of sufficient conditions
that guarantees the convergence of H-FRP programs (Chapter 4). Our main contribution
to implementation is a compiler for E-FRP that has been proved to be correct (Chapter
5). Finally, we also give some examples which illustrate the expressiveness of the RT-FRP
family of languages (Chapter 3, Chapter 4, and Chapter 5).
1.6 Notations
Here we introduce some common notations that will be used throughout this thesis. More
specialized notations will be introduced as they are first used. We refer the reader to the
11

notation table on page ix at the beginning of this thesis for a quick reference.
We write Ü Ý to denote that Ü and Ý are syntactically identical, Æ for the set of natural
numbers ½ ¾ ¡¡¡ , ÆÒ for the set of first Ò natural numbers ½ ¾ ¡¡¡ Ò , Ê for the set of
real numbers, and Ì for the set of times (non-negative real numbers).
The set comprehension notation ¾Ë is used for the set of formulas where is
drawn from the set Ë. For example, ¾Æ means ½ ¾ ¿ . When Ë is obvious
from context or uninteresting, we simply write instead.
Similarly, the sequence comprehension notation ¾Ë is used for the sequence of
formulas where is drawn from the sequence Ë. For example, ¾ ¾ ¿ ½ means the
sequence ¾ ¿ ½ . When Ë is obvious from context or uninteresting, we simply write
instead. The difference between a set and a sequence is that the order of elements in
a sequence is significant.
Finally, we adopt the following convention on the use of fonts: the Sans-Serif font is
used for identifiers in programs, the italic font is used for Ñ Ø -Ú Ö Ð × (i.e. variables that
stand for program constructs themselves), and the bold font is for program keywords.
1.7 Advice to the reader
The remainder of this thesis is organized as follows: Chapter 2 presents an expression
language BL that will be used by all variants of RT-FRP to express computations unrelated
to time. Chapter 3 presents the RT-FRP language, and establishes its resource bound
property. Then Chapter 4 introduces H-FRP, gives a continuous-time semantics to H-
FRP, and proves that under suitable conditions its operational semantics converges to its
continuous-time semantics as the sampling interval drops to zero. In Chapter 5 we present
E-FRP, as well as a provably correct compiler for it. Finally, Chapter 6 discusses future and
related work.
The reader is reminded that this thesis contains a lot of theorems and proofs. Casual or
first-time readers may choose to skip the proofs, and thus the bulk of them are relegated
12

to Appendix A.
Chapter summary
RT-FRP is a language for real-time reactive systems, where the program has to respond to
each stimulus using bounded space and time. With a carefully designed syntax and type
system, RT-FRP programs are guaranteed to be resource-bounded. This thesis presents
RT-FRP and its two variants (H-FRP and E-FRP) for hybrid systems and event-driven
systems. We establish the convergence property of H-FRP, and prove the soundness of
the compiler for E-FRP.
13

Chapter 2
A base language
The main entities of interest in a reactive system are behaviors (values that change over
time) and events (values that are only present at discrete points in time), both having a
time dimension. Therefore for RT-FRP to be a language for reactive systems, it must have
features to deal with time.
At the same time, to express interesting applications, RT-FRP must also be able to
perform non-trivial normal computations that do not involve time, which we call static
computations. For example, to program a reactive logic system, the programming lan-
guage should provide Boolean operations, whereas for a reactive digital control system,
the language should be able to do arithmetic. As these two examples reveal, different ap-
plications often require different kinds of static computations, and hence call for different
language features.
To make RT-FRP a general language for reactive systems, one approach is to make it so
big that all interesting applications can be expressed in it. This, however, is unappealing
to us because we believe that a single language, no matter how good, cannot apply to all
applications. This is the reason why we need domain-speciﬁc languages.
The reader might wonder why we cannot use a sophisticated enough language plus
customized libraries to accommodate for the differences between application domains.
Our answer is two-fold:
14

1. all libraries need to interface with the “universal” language, and therefore have to
share one type system, which can be too limiting; and
2. sometimes what matters is not what is in a language, but what is not in it: a “uni-
versal” language might have some features that we do not want the user to use, but
it is not easy to hide language features.
Therefore, our approach is to split the RT-FRP into two parts: a reactive language that
deals solely with time-related operations, and a base language that provides the ability to
write static computations. In this thesis we will focus on the design and properties of the
reactive language, while the user of RT-FRP can design or choose his own base language,
given that certain requirements are met.
To simplify the presentation, we will work with a concrete base language we call BL
(for Base Language). Our design goal for BL is to have a simple resource-bounded language
that is just expressive enough to encode all the examples we will need in this thesis. There-
fore we push for simplicity rather than power. As a result, BL is a pure, strict, first-order,
and simply-typed language.
The reader should remember that BL is just one example of what a base language can be,
and the user of RT-FRP is free to choose the base language most suitable for his particular
application domain, as long as the base language satisfies certain properties. To avoid
confusion, we will always write “the base language” for the unspecified base language
the user might choose, and write “BL” for the particular base language we choose to use
in this thesis.
2.1 Syntax
Figure 2.1 presents the abstract syntax of BL, where we use Ö, Ü, and for the syntactic
categories of real numbers, variables, and primitive functions, respectively.
An expression can be a ´µ (read “unit”), a real number Ö, an Ò-tuple of the form
15

Expressions ¿ ´µ
¬
¬ Ö
¬
¬ ´ ½ ¡¡¡ Òµ
¬
¬ Nothing
¬
¬ Just
¬
¬
¬
¬ let Ü in ¼ ¬
¬ Ü
¬
¬
case of Just Ü µ ½ else ¾
¬
¬
case of ´Ü½ ¡¡¡ ÜÒµ µ ¼
Values Î ¿Ú ´µ
¬
¬ Ö
¬
¬ ´Ú½ ¡¡¡ ÚÒµ
¬
¬ Nothing
¬
¬ Just Ú
Figure 2.1: Syntax of BL
´ ½ ¡¡¡ Òµ (where Ò ¾), an “optional” expression (Nothing or Just ), a function ap-
plication , a local definition (let-in), a variable Ü, or a pattern-matching expression
(case-of).
Nothing and Just are the two forms of “optional” values: Nothing means a value is
not present, while Just means that one is. Optional values will play a critical role in
representing events.
The let Ü in ¼ expression defines a local variable Ü that can be used in ¼. This
construct is not a recursive binder, meaning that the binding of Ü to is not effective in
itself. The reason for such a design is to ensure that a BL expression can always be
evaluated in bounded space and time.
The case-of expressions have two forms: the first deconstructs an optional expression,
and the second deconstructs an Ò-tuple.
BL is a first-order language. Therefore function arguments and return values cannot
be functions themselves. Since functions cannot be returned, function applications have
the form , where is a function constant, rather than ½ ¾. In this thesis, we do not fully
specify what can be. Instead, we just give some examples. The reason for doing this is
that the choice of functions does not affect our result for the RT-FRP language, as long as
the functions being used hold certain properties. For example, they should be pure (that
is, they generate the same answer given the same input) and resource-bounded (i.e. they
consume bounded time and space to execute). Actually, different sets of functions can be
used for different problem domains. This decoupling of function constants and the term
16

language makes BL a flexible base language, just as the decoupling of BL and the reactive
language makes RT-FRP more flexible.
For the purpose of this thesis, it is sufficient to allow to be an arithmetic operator (·,
, ¡, ), power function (pow where pow´ µ means “ raised to the power of ”), logic
operator ( , , ), comparison between real numbers ( , , =, , , ), or trigonometric
function (sin and cos).
In BL, functions all take exactly one argument. This is not a restriction as one might
suspect, since an Ò-ary function can be written as a unary function that takes an Ò-tuple as
its argument. For example, the · function takes a pair (2-tuple) of real numbers. However,
in many cases we prefer to use those binary functions as infix operators for the sake of
conciseness. Hence we write ¿ · ¾ and Ü½ Ü¾ instead of · ´¿ ¾µ and ´Ü½ Ü¾µ, although
the reader should remember that the former are just syntactic sugar for the latter.
When we are not interested in the value of a variable, we take the liberty of writing it
as an underscore ( ). This is called an anonymous variable, and cannot be referenced. Two
variables can both be anonymous while still being distinct. For example,
case of ´x µ µx
is considered semantically equivalent to
case of ´x y zµ µx
which returns the first field of a 3-tuple .
The reader might have noticed that BL has neither Boolean values nor conditional
expressions. This is because they can be encoded in existing BL constructs and therefore
are not necessary. To keep BL small, we represent False and True by Nothing and Just ´µ
17

respectively, and then the conditional expression
if then ½ else ¾
can be expressed as
case of Just µ ½ else ¾
From the grammar for and Ú, it is obvious that any value Ú is also an expression. In
other words, Î .
2.2 Type system
BL is a simply-typed ﬁrst-order language, which means that there are no polymorphic
functions and that all functions must be applied in full. Although the type system for BL
is not very interesting, we present it here for the completeness of this thesis.
2.2.1 Type language
The type language of BL is given by Figure 2.2.
Types « ´µ
¬
¬ Real
¬
¬ ´«½ ¡¡¡ «Òµ
¬
¬ Maybe «
Figure 2.2: Type language of BL
Note that ´µ is used in both the term language and the type language. In the term
language, ´µ is the “unit” value, and in the type language, it stands for the unit type, whose
only value is “unit,” or ´µ.
Real is the type for real numbers.
Similar to ´µ, the tuple notation ´ µ is used at both the term and the type level. In the
type language, ´«½ ¡¡¡ «Òµ is the type of an Ò-tuple whose -th ﬁeld has type « .
18

Maybe « is the type for optional values, which can be either Nothing or Just Ú where Ú
has type «.
We will use Bool as a synonym for the type Maybe ´µ, whose only values are Nothing
and Just ´µ. As said in Section 2.1, we let False and True be our preferred way of writing
Nothing and Just ´µ.
Since functions are not first-class in BL, we do not need to have function types in the
type language.
2.2.2 Context
The typing of BL terms is done in a variable context (sometimes simply called a context),
which assigns types to variables that occur free in an expression.
The free variables in an expression , written as Î ´ µ, are defined as:
Î ´ µ
Î ´´µµ Î ´Öµ Î ´´ ½ ¡¡¡ Òµµ
ËÒ
½ Î ´ µ
Î Ńothingµ Î ´Just µ Î ´ µ Î ´ µ Î ´ µ
Î ´let Ü in ¼µ Î ´ µ ´ Î ´
¼µ Ü µ Î ´Üµ Ü
Î ćase of Just Ü µ ½ else ¾µ Î ´ µ ´ Î ´ ½µ Ü µ Î ´ ¾µ
Î ćase of ´Ü½ ¡¡¡ ÜÒµ µ ¼µ Î ´ µ ´ Î ´
¼µ Ü½ ¡¡¡ ÜÒ µ
A context has the syntax
Ü «
We require the variables in a context to be distinct. Hence,
x Real y Real x ´µ
is not a context since the variable x occurs twice. We will only consider well-formed con-
19

texts in this thesis.
Notations
Before presenting the type system, we define some notations we will use with contexts.
We use for non-overlapping set union. Therefore, when the reader sees an expres-
sion of the form
it should be interpreted as , where .
Often we write
´Üµ «
to indicate the fact that
¼ Ü « for some
¼. Since a variable can occur at most
once in , it is obvious that if ´Üµ exists, it is uniquely determined. This justifies our use
of the function-like notation ´Üµ.
Given a context , its domain is defined as the set of variables occurring in , and
written as ÓÑ´ µ. The formal definition of ÓÑ´ µ is given by:
ÓÑ´ Ü « ¾Âµ Ü ¾Â
Finally, we write
¨ Ü «
for a context identical to except that Ü is assigned type « . The definition of ïs given
by:
¨
¼ Ü ´Üµ
¬
¬ Ü ¾ ÓÑ´ µ ÓÑ´
¼µ
Ü
¼´Üµ
¬
¬ Ü ¾ ÓÑ´
¼µ
The reader should note that ïs not commutative and therefore is not to be confused with
the set union operator .
20

2.2.3 Typing judgments
We use two judgments to deﬁne the type system of BL:
¯ « «¼: “ is a function from « to «¼;” and
¯ «: “ has type « in context .”
As shorthand, we write
½ ¡¡¡ Ò « «¼
for that ½ « «¼, . . . , and Ò « «¼.
BL is a ﬁrst-order monomorphic language, which makes its type system fairly easy to
understand. Figure ¾ ¿ presents the BL type system, which basically says:
The term ´µ has type ´µ, or unit. A real number Ö has type Real. A tuple ´ ½ ¡¡¡ Òµ
has type ´«½ ¡¡¡ «Òµ where has type « for all ¾ ÆÒ. Nothing and Just has type
Maybe « where has type «. A function « «¼ takes an expression of type « and
the result has type «¼.
Given a context , let Ü in ¼ has type «¼ where has type « in and ¼ has type «¼
in the context ¨ Ü « . Note that Ü is not added to to type , which corresponds to
the fact that let is not a recursive binder.
The type of a variable Ü is dictated by the context.
For case of Just Ü µ ½ else ¾, we require to have type Maybe «. Then the whole
expression is typed «¼ if ½ has type «¼ (with Ü assigned type «) and ¾ has type «¼.
Finally, case of ´Ü½ ¡¡¡ ÜÒµ µ ¼ has type «¼ where has type ´«½ ¡¡¡ «Òµ and ¼
has type «¼ (with Ü assigned type « for all ¾ÆÒ).
Generally speaking, in a functional language, a value can be represented as a closure,
which is a data structure that holds an expression and an environment of variable bind-
ings in which the expression is to be evaluated. In BL, a value term cannot contain free
variables, and therefore there is no need to include an environment in the representation
of a value. This suggests that the context is not relevant at all in the typing of a value. This
21

« «¼
· ¡ pow ´Real Realµ Real
Bool Bool ´Bool Boolµ Bool
´Real Realµ Bool sin cos Real Real
«
´µ ´µ Ö Real
« ¾ÆÒ
´ ½ ¡¡¡ Òµ ´«½ ¡¡¡ «Òµ
´Ò ¾µ
Nothing Maybe «
«
Just Maybe «
« «¼ «
«¼
« ¨ Ü « ¼ «¼
let Ü in ¼ «¼ Ü « Ü «
Maybe « ¨ Ü « ½ «¼ ¾ «¼
case of Just Ü µ ½ else ¾ «¼
´«½ ¡¡¡ «Òµ ¨ Ü « ¾ÆÒ ¼ «¼
case of ´Ü½ ¡¡¡ ÜÒµ µ ¼ «¼ ´Ü½ ¡¡¡ ÜÒ are distinctµ
Figure 2.3: Type system of BL
22

intuition is formalized by the following lemma:
Lemma 2.1 (Typing of values). Ú « ´µ Ú «.
Proof. The proof for the forward direction is by induction on the derivation of Ú «,
and the backward direction is proved by induction on the derivation of Ú «.
The decision of keeping values from containing free variables helps to ensure that a
value can always be stored in bounded space, which is not the case in general if values can
contain free variables. Also, having no free variables in values makes it easier to ensure
that any RT-FRP computation can be done in bounded time.
Lemma 2.1 shows that the type of a value Ú has nothing to do with the context in which
it is typed, and hence is an intrinsic property of Ú itself. Therefore, we can write
Ú ¾«
to indicate the fact that Ú « for some . With this notation, we can treat a type « as
the set of all values of that type, i.e. Ú
¬
¬ Ú « .
2.3 Operational semantics
Given an expression and the values of the free variables in , we expect to be able to
“evaluate” to some value Ú. The semantics of BL defines how we can find such a Ú.
In this section, we give a big-step operational semantics for BL, which is presented as a
ternary relation between , the binding of free variables in , and Ú.
We call the binding of values to variables an environment. The evaluation of an expres-
sion is always done in some particular environment. The syntax of an environment is
defined as
¿ Ü Ú
23

To distinguish from the signal environment that will be introduced in Chapter 3, we some-
times also call a variable environment.
We require variables defined in an environment to be distinct, hence justifying the use
of the notation
´Üµ Ú
for the fact that ¼ Ü Ú for some ¼.
Like what we do for contexts, we write
¨ Ü Ú
for an environment identical to except that Ü maps to Ú .
Often, we will need to assert that the variables are assigned values of the right types
in an environment, for which the concept of environment-context compatibility is invented:
Definition 2.1 (Environment-context compatibility). We say that Ü Ú ¾Â is
compatible with Ü « ¾Â, if for all ¾ Â we have Ú « . We write this as
.
As we said, the evaluation relation is between an expression , an environment , and
a value Ú. We use two evaluation judgments to define this relation:
¯ Ú ¸ Ú¼: “applying function to value Ú yields Ú¼;” and
¯ ¸ Ú: “ evaluates to Ú in environment .”
The functions and operators of BL have their standard semantics (for example, we
expect ¿ · ¾ ¸ ), and we hence omit the definition of the judgment Ú ¸ Ú¼. Figure 2.4
defines ¸ Ú.
2.4 Properties of BL
When designing the BL language, we expect it to have certain properties, such as:
24

¸ Ú
´µ ¸ ´µ Ö ¸ Ö
¸ Ú ¾ÆÒ
´ ½ ¡¡¡ Òµ ¸ ´Ú½ ¡¡¡ ÚÒµ
Nothing ¸ Nothing
¸ Ú
Just ¸ Just Ú
¸ Ú Ú ¸ Ú¼
¸ Ú¼
¸ Ú ¨ Ü Ú ¼ ¸ Ú¼
let Ü in ¼ ¸ Ú¼ Ü Ú Ü ¸ Ú
¸ Just Ú ¨ Ü Ú ½ ¸ Ú¼
case of Just Ü µ ½ else ¾ ¸ Ú¼
¸ Nothing ¾ ¸ Ú
case of Just Ü µ ½ else ¾ ¸ Ú
¸ ´Ú½ ¡¡¡ ÚÒµ ¨ Ü Ú ¾ÆÒ ¼ ¸ Ú
case of ´Ü½ ¡¡¡ ÜÒµ µ ¼ ¸ Ú
Figure 2.4: Operational semantics of BL
25

1. evaluating a well-typed expression should always lead to some value — the evalu-
ation process will not get stuck;
2. the evaluation relation should be deterministic, i.e. given , if evaluates to Ú in ,
then Ú is uniquely determined;
3. evaluation should preserve type: whenever evaluates to Ú, and Ú have the same
type; and
4. the evaluation of an expression can be done in bounded number of derivation steps.
In the rest of the section, we will establish these properties of BL. In Chapter 3, we will
use them to prove corresponding properties of RT-FRP. Uninterested readers can skip to
the next section now, and return later to reference these properties as the need arises.
First, we should give firm definitions to the properties we want to study:
Definition 2.2 (Properties of BL). We say that
1. BL is productive, if ´ « and µ µ Ú ¸ Ú;
2. BL is deterministic, if ´ ¸ Ú and ¸ Ú¼µ µ Ú Ú¼;
3. BL is type-preserving, if ´ «, , and ¸ Úµ µ Ú «; and
4. BL is resource-bounded, if given «, , and ¸ Ú, the size of the
derivation tree for ¸ Ú is bounded by a value that depends only on .
As BL is parameterized by a set of built-in functions, in order to establish these prop-
erties we need to define similar properties for functions:
Definition 2.3 (Properties of functions). Given a function « «¼, we say that:
1. is productive, if for all Ú ¾«, there is a Ú¼ such that Ú ¸ Ú¼;
2. is deterministic, if for all Ú, ´ Ú ¸ Ú¼ and Ú ¸ Ú¼¼µ µ Ú¼ Ú¼¼;
3. is type-disciplined, if for all Ú ¾«, Ú ¸ Ú¼ implies that Ú¼ ¾«¼; and
26

4. is resource-bounded, if for all Ú ¾«, Ú ¸ Ú¼ µ the size of the derivation tree for
Ú ¸ Ú¼ is bounded by a number that depends only on and Ú.
Now we can proceed to establish the properties of BL by a series of lemmas. First, we
repeat Lemma 2.1 here:
Lemma 2.1 (Typing of values). Ú « ´µ Ú «.
Next, we show that the evaluation of a well-typed expression will not get stuck:
Lemma 2.2 (Productivity). BL is productive if all functions are productive.
Proof. First, we need to prove the following proposition:
“If and ¾Â Ú « , then ¨ Ü « ¾Â ¨ Ü Ú ¾Â.”
The proof is by the deﬁnition of ¨and Lemma 2.1.
The rest of the proof for this lemma is by induction on the derivation of «, and
we will be using Lemma 2.4 which we will soon prove.
Given an expression, we expect that its value only depends on the free variables in it.
This intuition can be presented formally as:
Lemma 2.3 (Relevant variables). If all functions are deterministic, ¸ Ú, ¼
¸ Ú¼, and ´Üµ
¼´Üµ for all Ü ¾ Î ´ µ, then we have Ú Ú¼.
Proof. By induction on the derivation of ¸ Ú.
By directly applying Lemma 2.3, we get the following corollary:
Corollary 2.1 (Determinism). BL is deterministic if all functions are deterministic.
The next lemma assures us of the type of the return value when evaluating an expres-
sion:
Lemma 2.4 (Type preservation). BL is type-preserving if all functions are type-disciplined.
Proof. The proof is by induction on the derivation tree of «.
We are most interested in this property of BL:
27

Lemma 2.5 (Resource bound). BL is resource-bounded if all functions are resource bounded.
Proof. For any and where « and , the proof is by induction on the
derivation tree of «.
A BL value cannot contain free variables:
Lemma 2.6 (Free variables in values). For any given Ú, Î ´Úµ .
Proof. By induction on the structure of Ú.
Obviously, a value evaluates to itself in any environment:
Lemma 2.7 (Evaluation of value). For any given and Ú, Ú ¸ Ú.
Proof. By induction on the structure of Ú.
If we replace a free variable by its value in an expression , the value of should
remain the same:
Lemma 2.8 (Substitution). If Ü Ú ¸ Ú¼ and Ü Ú ¸ Ú¼¼, then
Ú¼ Ú¼¼.
Proof. By induction on the derivation of Ü Ú ¸ Ú¼. The critical case is when
Ü, where we need to show that Ü Ú Ü ¸ Ú and Ú ¸ Ú. The former
is by the deﬁnition of the operational semantics, and the latter is by direct application of
Lemma 2.7.
Furthermore, we can show that a value of type Maybe « must be in one of the two
forms Nothing and Just Ú:
Lemma 2.9 (Forms of optional values). Ú Maybe « implies that either Ú Nothing
or Ú Just Ú¼ for some Ú¼ where Ú¼ «.
Proof. By inspecting the typing rules in Figure 2.3.
28

Chapter summary
A reactive programming language needs to deal with both time-related computations and
static computations. We hence split RT-FRP into two orthogonal parts: a reactive language
and a base language. While the reactive language is ﬁxed, the user can choose the base
language for use with his particular application.
This chapter presents one instance of base languages called BL. BL is a pure, strict,
ﬁrst-order, and simply-typed language. A type system and an operational semantics are
given to BL. As preparation for establishing the resource-boundedness of RT-FRP, certain
properties of BL are also explored.
29

Chapter 3
Real-Time FRP
The Real-Time FRP (RT-FRP) language is composed of two parts: a base language for
expressing static computations and a reactive language that deals with time and reaction.
We have given an instance of base languages in the previous chapter. This chapter gives
a thorough treatment to the reactive language.
In addition to giving the syntax and type system of RT-FRP, we prove the resource-
boundedness of this language, which has been one of our primary design goals. We also
provide evidence that RT-FRP is practical by solving a variety of problems typical in real-
time reactive systems.
RT-FRP is deliberately small such that its properties can be well studied. For example,
it lacks mutually recursive signal definitions and pattern matching. Yet this language is
expressive enough that many of the missing features can be defined as syntactic sugar.
This chapter is organized as follows: Section 3.1 defines the syntax of the reactive part
of RT-FRP, and informally explains each construct. Section 3.2 presents an operational
semantics for untyped RT-FRP programs and the mechanics of executing an RT-FRP pro-
gram. Section 3.3 discusses the difference between the two kinds of recursion RT-FRP
supports. Section 3.4 explains what can go wrong with an untyped program, and solves
the problem by restricting the programs with a type system. Well-typed programs are
shown to run in bounded space and time in Section 3.5, where we also establish the space
30

and time complexity of executing a program. Section 3.6 discusses the expressiveness of
RT-FRP, using the example of a cruise control system. Finally, interested readers can find
some syntactic sugar for RT-FRP in Section 3.7 that makes it easier to use.
3.1 Syntax
To get the reader started with RT-FRP, we first present its syntax. The base language
syntax (terms and Ú) has been defined in the previous chapter. The reactive part of
RT-FRP is given by Figure 3.1, where Þ is the syntactic category of signal variables. Note
that base language terms can occur inside signal terms ×, but not the other way around.
Furthermore, a variable bound by let-snapshot can only be used in the base language.
Signals Ë ¿× input
¬
¬ time
¬
¬ let snapshot Ü ×½ in ×¾
¬
¬ ext
¬
¬
delay ×
¬
¬ let signal Þ ´Ü µ Ù in ×
¬
¬ Ù
Switchers Ù × until × µ Þ
Figure 3.1: Syntax of RT-FRP
The syntactic category Ù is for a special kind of signals called “switchers.” The reader
might question the necessity for a separate syntactic category for switchers. Indeed, we
can get rid of Ù and define × as:
× input
¬
¬ time
¬
¬ let snapshot Ü ×½ in ×¾
¬
¬ ext
¬
¬
delay ×
¬
¬ let signal Þ ´Ü µ × in ×
¬
¬ × until × µ Þ
However, this syntax accepts more programs that might grow arbitrarily large, and there-
fore requires a more complicated type system to ensure resource bounds. This is the rea-
son why we choose the current syntax.
Those familiar with FRP may have noticed that unlike FRP, RT-FRP does not have
31

syntactic distinction between behaviors (values that change over time) and events (values
that are present only at discrete points in time). Instead, they are unified under the syntac-
tic category signals. A signal that carries values of a “Maybe «” type is treated as an event,
and the rest of the signals are behaviors. We say that an event is occurring if its current
value is “Just something”, or that it is not occurring if its current value is “Nothing.” When
we know a signal is an event, we often name it as Ú to emphasize the fact.
To simplify the presentation of the operational semantics, but without loss of general-
ity, we require that all signal variables (Þ) in a program have distinct names.
In the rest of this section we explain each of the reactive constructs of RT-FRP in more
detail.
Primitive signals
The two primitive signals in RT-FRP are input, the current stimulus, and time, the current
time in seconds. In this paper we only make use of time, as it is sufficient for illustrating
all the operations that one might want to define on external stimuli. In practice, input
will carry values of different types – such as mouse clicks, keyboard presses, network
messages, and so on – for different applications, since there are few interesting systems
that react only to time.
Interfacing with the base language
The reactive part of RT-FRP does not provide primitive operations such as addition and
subtraction on the values of signals. Instead, this is relegated to the base language. To
interface with the base language, the reactive part of RT-FRP has a mechanism for export-
ing snapshots of signal values to the base language, and a mechanism for importing base
language values back into the signal world. Specifically, to export a signal, we snapshot
its current value using the let-snapshot construct, and to invoke an external computation
in the base language we use the ext construct.
32

To illustrate, suppose we wish to deﬁne a signal representing the current time in min-
utes. We can do this by:
let snapshot t time in ext ´t ¼µ
To compute externally with more than one signal, we have to snapshot each one sepa-
rately. For example, the term:
let snapshot x ×½ in
let snapshot y ×¾ in ext ´x · yµ
is a signal that is the pointwise sum of the signals ×½ and ×¾.
Accessing previous values
The signal delay × is a delayed version of ×, whose initial value is the value of .
To illustrate the use of delay, the following term computes the difference between the
current time and the time at the previous program execution step:
let snapshot t0 time in
let snapshot t1 delay ¼ time in ext ´t0 t1µ
Switching
As in FRP, a signal can react to an event by switching to another signal. The let-signal
construct deﬁnes a group of signals (or more precisely signal templates, as they are each
parameterized by a variable). Each of the signals must be a switcher (an until construct),
which has the syntax “× until × µ Þ ” and is a signal × that switches to another signal
Þ when some event × occurs. For example,
× until ×½ µÞ½ ×¾ µÞ¾
33

initially behaves as ×, and becomes Þ½´Úµ if event ×½ occurs with value Ú, or becomes Þ¾´Úµ
if ×½ does not occur but event ×¾ occurs with value Ú. Please note that a switcher switches
only once and then ignores the events. Section 3.7.5 shows how repeated switching can
be done in RT-FRP.
Signal templates introduced by the same let-signal construct can be mutually recur-
sive, i.e. they can switch into each other. However, as we will see in Section 3.4.1, unre-
stricted switching leads to unbounded space consumption. Hence when defining the type
system of RT-FRP in Section 3.4, we will impose subtle restriction on recursive switching
to make sure it is well-behaved.
As an example of switching, a sample-and-hold register that remembers the most re-
cent event value it has received can be defined as:
let signal hold´xµ éxt xµ until × ÑÔÐ µhold
in éxt ¼µ until × ÑÔÐ µhold
This signal starts out as ¼. Whenever the event × ÑÔÐ occurs, its current value is substi-
tuted for x in the body of hold´xµ, and that value becomes the current value of the overall
signal. As we will see in Section 3.7.7, the underlined part can be simplified to hold´¼µ
using syntactic sugar.
A switcher Ù may have arbitrary number of switching branches, including zero. When
there is no switching branch, Ù has the form “× until ,” and behaves just like × since there
is no event to trigger it to switch. Indeed, as we will see in Section 3.2, “× until ” and “×”
have the same operational semantics.
It is worth pointing out though that “× until ” is a switcher while “×” is not. Since the
definition bodies in a “let-signal” must be switchers, the programmer must use “× until ”
instead of “×” there. After seeing the type system in Section 3.4, the reader will discover
that “× until ” and “×” follow different typing rules, which is necessary to ensure the
resource-boundedness of RT-FRP.
34

3.2 Operational semantics
Now that we have explained what each construct in RT-FRP does, the reader should have
some intuition about how to interpret an arbitrary RT-FRP program. To transform the in-
tuition into precise understanding, we present the full details of the operational semantics
of RT-FRP in this section.
3.2.1 Environments
Program execution takes place in the context of a variable environment (as defined in
Section 2.3) and a signal environment :
Þ Ü Ù
The variable environment is used to store the current values of signals, and hence maps
signal variables to values. The signal environment maps a signal variable to its defini-
tion. The lambda abstraction makes explicit the formal argument and the signal parame-
terized by that argument.
3.2.2 Two judgment forms
We define the single-step semantics by means of two judgments:
¯ ×
Ø
¸ Ú: “× evaluates to Ú on input at time Ø, in environment ;” and
¯ ×
Ø
×¼: “× is updated to become ×¼ on input at time Ø, in environments
and .”
Sometimes we combine the two judgments and write
×
Ø
¸ Ú ×¼
35

When the environments are empty, we simplifies the notation further to
×
Ø
¸ Ú ×¼
Note that the evaluation of a term × does not depend on the signal environment, and
the semantics for each step is parameterized by the current time Ø and the current input .
The role of evaluation is to compute the output of a term. The role of updating is to
modify the state of the program. We present the rules of each of these judgments in Figure
3.2 and 3.3.
The overall execution, or “run”, of an RT-FRP program is modeled as an infinite se-
quence of interactions with the environment, and in that sense does not terminate. For-
mally, for a given sequence of time-stamped stimuli ´Ø¼ ¼µ ´Ø½ ½µ , a run of an RT-
FRP program ×¼ produces a sequence of values Ú¼ Ú½ , where ×
Ø
¸ Ú × ·½ for all
¾ ¼ Æ. Thus, a run can be visualized as an infinite chain of the form:
×¼
Ø¼ ¼
¸ Ú¼ ×½
Ø½ ½
¸ Ú½ ×¾ ×Ò
ØÒ Ò
¸ ÚÒ ×Ò·½
or as in the following figure:
s0
t0
, i0
v0
s1
t1
, i1
v1
sn
tn
, in
vn
... ...
where we use “ ” for update of terms, and “ Ã” for flow of data.
Next, we explain the judgment rules in detail.
36

input
Ø
¸
é1µ
time
Ø
¸ Ø
é2µ
¸ Ú
ext
Ø
¸ Ú
é3µ
¸ Ú
delay ×
Ø
¸ Ú
é4µ
×½
Ø
¸ Ú½
¨ Ü Ú½ ×¾
Ø
¸ Ú¾
let snapshot Ü ×½ in ×¾
Ø
¸ Ú¾
é5µ
×
Ø
¸ Ú
let signal Þ ´Ü µ Ù in ×
Ø
¸ Ú
é6µ
×
Ø
¸ Ú
× until × µ Þ
Ø
¸ Ú
é7µ
Figure 3.2: Operational semantics for RT-FRP: evaluation rules
3.2.3 The mechanics of evaluating and updating
Evaluating the input and time constructs simply returns the current value for the input
and the time, respectively (rules e1 and e2). Updating these two constructs leaves them
unchanged (rules u1 and u2).
The evaluation rule for calls to the base language (rule e3) uses the judgment
¸ Ú to evaluate the BL term , which was defined in Section 2.3. The term ext is not
changed by updating (rule u3).
The instantaneous value of delay × is just the value of (rule e4). But it is updated
to a new term delay Ú¼ ×¼, where Ú¼ is the previous instantaneous value of ×, and ×¼ is the
new term resulting from updating × (rule u4).
Evaluation of let snapshot Ü ×½ in ×¾ consists of two stages: first, ×½ is evaluated to
get Ú; second, ×¾ is evaluated with Ü bound to Ú, yielding the result (rule e5). Updating
the term is done by updating both ×½ and ×¾ (rule u5).
37

input
Ø
input
ú1µ
time
Ø
time
ú2µ
ext
Ø
ext
ú3µ
×
Ø
¸ Ú¼ ×¼
delay ×
Ø
delay Ú¼ ×¼
ú4µ
×½
Ø
¸ Ú½
¨ Ü Ú½ ×½
Ø
×¼
½ ¨ Ü Ú½ ×¾
Ø
×¼
¾
let snapshot Ü ×½ in ×¾
Ø
let snapshot Ü ×¼
½ in ×¼
¾
ú5µ
¨ Þ Ü Ù ×
Ø
×¼
Ø
let signal Þ ´Ü µ Ù in ×¼
ú6µ
×
Ø
¸ Nothing ¾ÆÑ ½ ×Ñ
Ø
¸ Just Ú
ÞÑ Ü Ù × until × µ Þ
Ø
Ù Ü Ú
ú7µ
×
Ø
×¼ ×
Ø
¸ Nothing ×¼
× until × µ Þ
Ø
×¼ until ×¼ µ Þ
ú8µ
Figure 3.3: Operational semantics for RT-FRP: updating rules
38

The evaluation of let-signal and until (rules e6 and e7) is straightforward with one
exception: the value returned by × until × µ Þ does not depend on any of the events
× , i.e. when an event × occurs, × until × µ Þ still returns the value of ×. Such
is called delayed switching. An alternative design is immediate switching, where when ×
occurs, × until × µÞ returns the value of the behavior just being switched into.
The reason we pick the delayed switching design is to allow the user to define signals
that react to themselves, such as
let snapshot x × until ext ´x ½¼µ µÞ
in ext x
which is initially × and switches to the signal Þ when the value of itself exceeds 10. This
program will get stuck if executed using the immediate switching semantics.
Note that ext ´x ½¼µ is a Boolean signal, but is used as an event here. We can do
this because the Boolean type is just synonym of “Maybe ()” in BL (see Section 2.1), which
means any Boolean signal is automatically an event of unit.
The updating rules for let-signal and until are more involved. For the construct
the signal definition group Þ ´Ü µ Ù is unchanged, and × is executed with the signal
environment extended with the new definitions (rule u7). For the construct
× until × µÞ
the events × are tested one after another until the first occurrence, then the signal
evolves to the definition of the corresponding signal, with its formal parameter replaced
by the value of the event (rule u7). If no event occurs, then we get back the original term
with the sub-terms updated (u8).
39

Please be reminded that we require that all signal variables in an RT-FRP program
are distinct, otherwise the rules u6 and u7 will not work. For example, if we allow the
program
let signal z1´ µ ×½ until Ú µz2
z2´ µ ×¾ until Ú µz1
in let signal z2´ µ ×¿ until Ú µz2
in ×¼ until Ú µz1,
we would expect that the inner definition of z2 will not interfere with the outer definition
of the same variable, and that the z2 in the body of z1 still refers to the outer definition.
Consequently, we would expect the program to exhibit the behavior
×¼ ×½ ×¾ ×½ ×¾ ¡¡¡
as the event Ú occurs repeatedly. However, the behavior we get by following the semantic
rules will actually be
×¼ ×½ ×¿ ×¿ ×¿ ¡¡¡
which is not what we want. This will not happen if we rename the inner z2 to z3.
The source of this problem is that the definition of a signal variable can contain free
signal variables, and thus should be represented by a closure in the environment. Indeed,
we could do that and hence relax the requirement that all signal variables are distinct.
However, our current representation is simpler notation-wise, and thus is used.
3.3 Two kinds of recursion
In a reactive system, there can be two kinds of cyclic structures that exhibit recursion in
RT-FRP. One is control feedback (feeding the output of a system to its own input), and the
other is cycles in a state-transition diagram. RT-FRP has different recursive constructs to
40

support them, which we will discuss one by one.
3.3.1 Feedback
Reactive systems often involve feedback, which corresponds to recursive let-snapshot in
RT-FRP. For example, the velocity of a mass Ñ under force and friction Ú can be de-
scribed by the block diagram:
- 1/m
k
f v
or more concisely by the recursive integral equation:
Ú ´ Úµ ÑdØ
The RT-FRP encoding for this signal is simply:
let snapshot v integral éxt ´f k ¡vµ mµin ext v
where integral will be defined as syntactic sugar in Section 3.7.
An important use of feedback is to add local state to a system. For example, a general
expression of the form:
let snapshot Ü delay ×½ in ×¾
defines a signal with a local state Ü. The initial value of Ü is that of . In each time step
after that, the new state (i.e. the new value of Ü) is the previous value returned by ×½,
which can depend on the previous value of Ü. As a more concrete example, we can define
the running maximum of a signal × as follows:
41

let snapshot cur × in
let snapshot rmax delay ´ ½µ éxt maxćur rmaxµµ in
ext rmax
where max is a BL function that returns the larger of two real numbers. The definition is
illustrated by the diagram:
max delay (-infinity)
cur
rmax
rmax is ½ in the initial step. At the ´Ò · ½µ-th step, it is updated to be the larger one
of its previous value and the value of × at step Ò. Therefore rmax records the maximum
value of × up to the previous step.
3.3.2 Cycles in a state transition diagram
RT-FRP provides two constructs, namely let-signal and until, that allow the definition
of multi-modal signals, that is, signals that shift from one operating mode to another with
the occurrences of events. For example, here is a multiplexer that switches between two
signals ×½ and ×¾ whenever the event ×Û Ø occurs:
s1
s2
switch
output
The state-transition diagram of this multiplexer is:
42

pick1
start
pick2
switch
switch
and it can be encoded in RT-FRP by the following program:
let snapshot i1 ×½ in
let snapshot i2 ×¾ in
let snapshot s ×Û Ø in
let signal pick1´ µ éxt i1µ until ext s µpick2
pick2´ µ éxt i2µ until ext s µpick1 in
éxt i1µ until ext s µpick2 .
As shown in the above example, the let-signal definitions can be mutually recursive,
in which case the corresponding state transition diagram of the system is cyclic.
3.3.3 Recursion in FRP
Those familiar with FRP might recall that there is no syntactic distinction between the two
forms of recursion in FRP. For example, the FRP program
v integral ´´f k ¡vµ mµ
implements the velocity-of-mass example shown at the beginning of this section, and uses
recursion for feedback; whereas the FRP program
timer íntegral ½µ until reset µtimer
43

(assuming suitable definition for the event reset) uses recursion for switching back to a
mode, as shown below:
integral 1 reset
start
Yet, in both cases the same recursion syntax is used. We feel that this in practice can
create confusion about the program. For example, it is not obvious what the following
FRP program means:
u íntegral ´´f k ¡uµ mµµ until reset µu
In RT-FRP, these two forms of recursion are clearly distinguished using different lan-
guage constructs: a recursive let-snapshot introduces a feedback, while let-signal is used
to define recursive switching. Therefore, the two examples are written in RT-FRP as
let snapshot v integral éxt ´´f k ¡vµ mµµ
and
let signal timer´ µ integral ½ until ext reset µtimer
respectively, where integral is defined as syntactic sugar in Section 3.7.2. We feel this is
an improvement over the FRP syntax.
3.4 Type system
Although we have already defined the syntax and semantics of RT-FRP, the specification
is not complete without a type system. This section explains why we need a type system
for RT-FRP, what it is like, and what the intuition behind it is.
44

3.4.1 What can go wrong?
RT-FRP supports two forms of recursion [12]: feedback as defined by let-snapshot, and
recursive switching as defined by let-signal and until. Unrestricted use of these two forms
of recursion can cause programs to get stuck or use unbounded space at run-time.
Getting stuck
Untyped programs that use let-snapshot can get stuck. For example, evaluating
let snapshot x ext x in ext x
requires evaluating ext x in an environment where x is not bound (rule e5), and hence
gets stuck. The essence of this problem is that for a signal let snapshot Ü ×½ in ×¾, any
occurrence of Ü in ×½ should not be needed during the evaluation of ×½, although it could
be used during updating ×½. In fact, the distinction between evaluation and updating
exists primarily so that evaluation can be used to “bootstrap” the recursion in an early
phase, so that we can give a sensible notion of updating to such expressions.
A major design goal for the RT-FRP type system is to ensure that the above situation
does not arise at run time.
Using unbounded space
In a switcher × until × µ Þ , if the initial signal × contains a free signal variable, then
the term might grow arbitrarily large during execution. One example is the program
fragment
let signal z´ µ ´×¼ until Ú¼ µzµ until Ú½ µz
in ×½ until Ú¾ µz
where the initial signal for the definition of z´ µ is “×¼ until Ú¼ µ z,” which has a free
signal variable z.
45

When Ú¾ occurs, this term becomes
in ´×¼ until Ú¼ µzµ until Ú½ µz
Now if Ú¼ occurs but Ú½ does not, the term in turn becomes
in ´´×¼ until Ú¼ µzµ until Ú½ µzµ until Ú½ µz
From this point on, it is clear that as long as Ú½ does not occur, every time Ú¼ occurs, the
program becomes larger.
For a similar reason, we do not want to allow any × in × until × µÞ to contain free
signal variables. As an exercise, the reader can determine the condition under which the
following program fragment can grow arbitrarily large:
let signal z´ µ ×¼ until ´×½ until Ú¼ µzµ µz
in ×¾ until Ú½ µz
3.4.2 Typing rules
We have seen how untyped programs can go wrong at run time. Our approach to prevent
such run-time errors is to use a type system to reject those ill-behaved programs. This
section presents such a type system.
Types
For simplicity of presentation, we do not explicitly distinguish between the signal types
for RT-FRP and the types provided by the base language. The meaning of these types will
vary depending on whether they are assigned to base language terms or RT-FRP signals.
In the ﬁrst case, « will have its usual interpretation. In the second case, it will mean “a
46

signal carrying values of type «”.
Contexts
The typing of RT-FRP programs is done in two variable contexts and one signal context.
The variable contexts and ¢ are functions from variables to types, as defined in Section
2.2.
Two variable contexts are needed to ensure that the phase distinction between the
evaluation of a term and updating a term is reflected in enough detail so as to allow us to
guarantee type preservation in the presence of recursion.
We will also treat context functions as sets (their graph). The reader is again advised
that we require all signal variables in a program to be distinct.
A signal context ¡ is a function from signal variables to types.
Signal contexts ¡ Þ « «¼
A binding Þ « «¼ in ¡ means that Þ is a signal of type «¼ parameterized by a variable
of type «.
Typing judgment
Figure 3.4 defines the RT-FRP type system using a judgment
¢ ¡ S × «
read “× is a signal of type « in contexts ¢, and ¡.” Intuitively, contains variables that
can be used in evaluating and updating ×, while ¢ contains variables that can be used in
the updating, but not evaluation, of ×. The signal context ¡ assigns types to all free signal
variables in ×. To simplify the typing rules, we require that all base language variables and
signal variables in a program are distinct.
47

The signal input has type Input, a placeholder for the signature of the external stimuli
visible to the system. Depending on the application, Input can be instantiated to any type
in the BL language.
The signal time has type Real. The term ext is a signal of type « when is a base
language term of type «. In this typing rule, is typed without using ¡. Intuitively, this
means that signal variables cannot be exported to the base language.
The type of delay × is the type of ×, given that the base language term has the same
type.
A term let snapshot Ü ×½ in ×¾ has the same type as ×¾, assuming that ×½ is well-
typed. The typing reflects the fact that this is a recursive binding construct, and that Ü can
occur anywhere.
A group of mutually recursive signals are defined by let-signal. A signal definition
has the form Þ´Üµ Ù, where Ü is the formal parameter for Þ, and Ù (a switcher) is the
definition body. The type of let signal ¡¡¡ in × is the same as the type of ×.
In a term × until × µ Þ , the type of an event × must match the parameter type of
the signal template Þ , and the result type of all Þ must be the same as the type of ×. Note
that none of the sub-terms × and × can contain free signal variables, as shown by the rule
t7.
3.4.3 How it comes about
The reader might still be wondering why we designed the type system to be the way it is.
This section explains some of the intuition behind our design. Uninterested readers can
skip this section, as it will not affect the understanding of the rest of the thesis.
Typing of delay
The typing rule for delay (rule t4) has a side condition requiring that any value Ú typed
« in context can also be typed « in the empty context. This is a property of the base
48

¢ ¡ S input Input
´t1µ
¢ ¡ S time Real
´t2µ
«
¢ ¡ S ext «
´t3µ
Ú Ú « µ Ú «
« ¢ ¡ S × «
¢ ¡ S delay × «
´t4µ
¢ Ü «½ ¡ S ×½ «½
Ü «½ ¢ ¡ S ×¾ «¾
¢ ¡ S let snapshot Ü ×½ in ×¾ «¾
´t5µ
Ü « ¢ ¡ ¡
¼
S Ù «¼ ¾Â
¢ ¡ ¡
¼
S × « ¡
¼ Þ « «¼ ¾Â
¢ ¡ S let signal Þ ´Ü µ Ù ¾Â in × «
´t6µ
¢ S × « ¢ S × Maybe «
¢ ¡ Þ « « S × until × µ Þ «
´t7µ
Figure 3.4: Type system for RT-FRP
language and the type «.
In BL, values cannot contain free variables and therefore the side condition is satisﬁed
for all types «, as Lemma 2.1 shows. Nonetheless, this might not be the case for other base
languages. For example, in a base language that supports some form of -calculus, the
-abstraction “ x x y · z” is a value, but it contains free variables and therefore cannot
be typed in the empty context.
The motivation for the side condition in rule t4 is to ensure that the execution of a
program preserves its well-typedness. Consider the following program È where the base
language supports -calculus:
let snapshot x let snapshot f delay ´ y yµ ´ext y xµ
in ext ´f ¼µ
in ext x
This program is well-typed if rule t4 does not have the side requirement. However, when
49

È is executed, it will be updated to the following program È ¼ in the first step:
let snapshot x let snapshot f delay ´ y xµ éxt y xµ
in ext ´f ¼µ
in ext x
where the underlined part has changed. È ¼, however, defines the value of x as ´ y xµ ¼,
which is a cyclic definition, and therefore is not well-typed.
Typing of let-signal and until
We can say that the syntax and typing rules for let-signal and until are the essence of
the RT-FRP language: they together ensure the program size to be bounded while allow-
ing interesting recursive-switching programs. This section explains some of the intuition
behind the design of these two constructs.
The typing of RT-FRP programs is done in a pair of variable environments ( and ¢)
and a signal environment (¡). Roughly speaking, and ¢ ensure that the execution of a
program does not get stuck (i.e. the value of a variable is known when it is needed), while
¡ ensures that the size of a program does not exceed a bound.
Therefore, the best way to understand the typing rules for let-signal and until is prob-
ably to project them into two views. First, we focus on the variable environments and
¢:
Ü « ¢ ¡¡¡ S Ù «¼ ¾Â
¢ ¡¡¡ S × «
¢ ¡¡¡ S let signal Þ ´Ü µ Ù ¾Â in × «
´t6µ
¢ ¡¡¡ S × « ¢ ¡¡¡ S × Maybe «
¢ ¡¡¡ S × until × µ Þ «
´t7µ
Now it is clear that t6 adds Ü to the current environment when typing Ù , and that t7 al-
lows × to freely use variables from both the current and the delayed environment, which
50

corresponds to the “delayed switching” semantics for until.
Next we focus on the signal environment:
¡¡¡ ¡ ¡
¼
S Ù «¼ ¾Â
¡¡¡ ¡ ¡
¼
S × « ¡
¼ Þ « «¼ ¾Â
¡¡¡ ¡ S let signal Þ ´Ü µ Ù ¾Â in × «
´t6µ
¡¡¡ S × « ¡¡¡ S × Maybe «
¡¡¡ ¡ Þ « « S × until × µ Þ «
´t7µ
The rule t6 shows that signals deﬁned in this let-signal group and the enclosing let-signal
groups can both be used in × and Ù . The rule t7 says that neither × nor × in × until × µ
Þ can have any free signal variable.
We impose such restrictions because, as we have shown in Section 3.4.1, a term can
grow arbitrarily large without them.
3.5 Resource bound
In this section we prove the basic resource-boundedness properties of RT-FRP, namely,
that the time and space in each execution step is bounded:
Theorem 3.1 (Resource bound). For any closed and well-typed program, we know that
1. its single-step execution terminates and preserves types, and
2. there is a bound for the time and space it needs during execution.
The proof of the ﬁrst part of this theorem is a special instance of Lemma 3.3. The proof
of the second part requires formalizing notions of cost and showing that they are bounded
during the execution of any program. In the rest of this section, we present the technical
details required to establish this result.
51

3.5.1 Type preservation and termination
This section establishes some basic properties of RT-FRP useful for proving its resource-
boundedness. Uninterested readers can skip this section.
Compatibility
In order to express the type safety property concisely, we must have a concise way for
expressing the necessary constraints on the environments involved in the statement of
the properties. In general, we will need to assume that an environment is compatible
with a context . We write this relation as , which was defined in Section 2.3.
Similarly, we define ¢ ¡ (read “the signal environment is compatible with
the contexts , ¢, and ¡”) as follows:
¢ ¡
¨ Ü « ¢ ¡ S Ù «¼ ¾Â
¡ Þ « «¼ ¾Â
¢ ¡ Þ Ü Ù ¾Â
It is easy to show the above definition enjoys the following forms of weakening:
Lemma 3.1 (Basic properties).
¢
Ú «
¨ Ü « ¨ Ü Ú
¢ ¡ ¢ ¡
¼ ¼
¢ ¡ ¡
¼ ¼
¢ Ü « ¡ × «¼
¢ Ü « ¡ × «¼
Assumptions about the base language
In order to prove the key properties of RT-FRP, we must be explicit about our assumptions
about the base language. We assume three key properties of the base language: First, that
evaluation terminates and preserves typing. Second, that values of Maybe « types either
52

are Nothing or have the form Just Ú. Third, that the type system enjoys substitutivity.
These requirements are formalized as follows:
«
Ú ´ ¸ Ú Ú «µ
Ú Maybe «
Ú Nothing or Ú¼ ´ Ú Just Ú¼ Ú¼ « µ
« Ü « ¼ «¼

¼ Ü «¼
It is easily verified that BL satisfies these properties.
Type preservation and termination
Using the substitutivity assumption about the base language, it is now possible to estab-
lish the following lemma for RT-FRP:
Lemma 3.2 (Substitution). Whenever Ú « and Ü « ¢ ¡ S × «¼, we have
¢ ¡ S × Ü Ú «¼.
Next, we show this important lemma:
Lemma 3.3 (Type preservation and termination). For all , ¢, ¡, , , ×, and «,
1. if and ¢ ¡ S × «, then there exists a value Ú such that ×
Ø
¸ Ú and
Ú «, and
2. if ¢ , and ¢ ¡ and ¢ ¡ S × «, then there exists a term ×¼ such
that ×
Ø
×¼ and ¢ ¡ S ×¼ «.
Proof. The proof of both parts is by induction over the height of the typing derivation.
The proof of the first part uses the assumptions about the base language to establish the
53

soundness of the ext construct. The proof of the second part uses the substitutivity prop-
erty, and the first part of the lemma.
After this property is established, it is easy to see that not only is evaluation always
terminating, but it is also deterministic whenever the base language is also deterministic.
3.5.2 Resource boundedness
Having established that the language is terminating, we now come to the proof of the
second part of our main theorem, namely, time- and space-boundedness. As a measure
of the time and space needed for executing a program, we will use term size at run-time
(modulo the size of base language terms). This measure is reasonable because of two
observations: First, the size of a derivation tree is bounded by the term size. Second, the
derivation is syntax directed, and so the time needed to propagate the information around
a rule is bounded by the size of the term (assuming a naïve implementation, where each
term is copied in full). Thus, our focus will be on showing that there exists a measure on
programs that does not increase during run-time.
We formally define the size of a term ×, written × , to be the number of constructors,
base language expressions, and signals in the term:
input ½
time ½
ext ¾
delay × ¾ · ×
let snapshot Ü ×½ in ×¾ ¾ · ×½ · ×¾
¬
¬let signal Þ ´Ü µ Ù ¾ÆÒ in ×
¬
¬ ½ · ¾Ò · ¦
Ò
½ Ù · ×
¬
¬× until × µÞ ¾ÆÒ
¬
¬ ½ · Ò · × · ¦
Ò
½ ×
We must show the well-formedness of the definition of :
Lemma 3.4. × is defined for all ×.
54

The proof is by induction on × and can be found in Appendix A.1.
As mentioned earlier, the size of a term can grow at run-time. However, we can still
show that there exists a bound for the size of the term at run-time. The following function
on terms (where Ñ is an integer) will be used to define such a bound:
input Ñ ½
time Ñ ½
ext Ñ ¾
delay × Ñ ¾ · × Ñ
let snapshot Ü ×½ in ×¾ Ñ ¾ · ×½ Ñ · ×¾ Ñ

let signal Þ ´Ü µ Ù ¾ÆÒ in ×

Ñ
½ · ¾Ò · ¦
Ò
½ Ù · × Ñ Ü Þ Ü Ù ¾ÆÒ Ñ

× until × µÞ ¾ÆÒ

Ñ
Ñ Ü
Ò
½ · Ò · × ¼ · ¦
Ò
½ × ¼ Ñ
Ó
where Þ Ü Ù is given by:
Þ Ü Ù Ñ Ü

¼
¨
Ù ¼
©¡
The idea is that assuming Ñ is the size bound for the free signal variables in ×, × Ñ gives
the size bound for ×.
Since input, time, and ext do not change during execution, their size bounds are sim-
ply their sizes. The terms delay and let-snapshot are updated by updating their respective
sub-terms. This explains the definition of delay × Ñ and let snapshot Ü ×½ in ×¾ Ñ.
When we update the term ×¼ let signal Þ ´Ü µ Ù in ×, the signal variable defini-
tions are not touched, and we just update the sub-term ×. To understand the definition of
let signal Þ ´Ü µ Ù in × Ñ, we consider an arbitrary free signal variable Þ in ×. We
know that either Þ is a free variable in ×¼, in which case Ñ is a bound for Þ, or Þ Þ for
55

some , in which case Ñ Ü
¨
Þ Ü Ù ¾ÆÒ

Ñ
©
is a bound for Þ. In neither case can
Þ grow larger than Ñ Ü
¨
Þ Ü Ù ¾ÆÒ

Ñ
©
.
To define ×¼
Ñ where ×¼ × until × µÞ ¾ÆÒ , we note that × and × cannot contain
free signal variables. Therefore, when no switching occurs, ×¼ cannot grow larger than
½ · Ò · × ¼ · ¦
Ò
½ × ¼, and when a switching to some Þ occurs, ×¼ cannot grow larger
than Ñ since Ñ (by definition) is an upper bound for Þ . Hence, the bound for ×¼ is the
maximum of ½ · Ò · × ¼ · ¦
Ò
½ × ¼ and Ñ.
Of course, we need to prove the well-definedness of × Ñ:
Lemma 3.5. For all term × and integer Ñ, × Ñ is defined.
The proof is again by induction on × and can be found in Appendix A.1.
In order to establish the bound, we must always consider a term in the context of
a particular signal environment. Thus we define the term size bound for a term × under
signal environment to be × . First, it is useful to know that this measure is an
upper bound for term size × :
Lemma 3.6. For all term × and integer Ñ, × × Ñ.
This lemma can be proved by induction on ×. The full proof is presented in Appendix
A.1.
Now we can show that even though term size can grow during execution, its size
bound as defined by does not:
Lemma 3.7 (Bound preservation). ×
Ø
×¼ implies ×¼ × .
The proof is by induction on the derivation for ×
Ø
×¼, and can be found in
Appendix A.1.
3.5.3 Space and time complexity of terms
A natural question to ask is: for a program × of size Ò (i.e. × Ò), how large can × Ñ
be? Is it Ç´Òµ, Ç´Ò¾µ, Ç´¾
Òµ, or something else? We find that the worst case of × Ñ is
56

exponential with respect to × :
Lemma 3.8. For any term × and integer Ñ ¼, we have that × Ñ Ñ Ü ½ Ñ ¡¾
× .
The proof is by induction on ×, and is presented in Appendix A.1. As the execution
time is bounded by the term size, Ñ Ü ½ Ñ ¡¾
× also gives the time complexity of exe-
cuting the program ×.
An exponentially growing program
Lemma 3.8 shows that a term can grow at most exponentially with respect to its initial
size, but can this really occur? This section shows that the answer is yes by constructing
such an example.
We inductively define a series of Ñ programs È ¾ÆÑ , where:
È½ let signal Þ½´ µ × until in
let snapshot x éxt ¼µ until Ú µÞ½ in
(ext ¼µ until Ú µÞ½
and for all ¾ÆÑ ½,
È ·½ let signal Þ ·½´ µ È until in
let snapshot x éxt ¼µ until Ú µÞ ·½ in
éxt ¼µ until Ú µÞ ·½
where × and Ú are defined as
× ext ¼, and
Ú delay ´Just ´µµ éxt Nothingµ
Note that Ú is an event that occurs once in the initial step, and then never occurs again.
57

By the definition of , we can calculate the sizes of the programs as:
È½ ¿ · × until · let snapshot x éxt ¼µ until Ú µÞ½ in éxt ¼µ until Ú µÞ½
¿ · ´½ · × µ · ´¾ · éxt ¼µ until Ú µÞ½ · éxt ¼µ until Ú µÞ½ µ
· × · ¾ ¡ éxt ¼µ until Ú µÞ½
· × · ¾ ¡´¾ · ext ¼ · Ú µ
· × · ¾ ¡´¾ · ¾ · µ
¾¾ · ×
We notice that È ·½ has the same structure as È½, except that È is substituted for ×. Hence
we have
È ·½ ¾¾ · È
Considering the initial condition È½ ¾¾ · × , we get that
È ¾¾ · × for all ¾ÆÑ.
Let È be the new program obtained by executing È for steps. Apparently
È½
½ let signal Þ½´ µ × until in
let snapshot x × until in
× until
and for all ¾ÆÑ ½,
È½
·½ let signal Þ ·½´ µ È until in
let snapshot x È until in
È until
What’s more, for all ¾ÆÑ ½ and ¾Æ , we have
58

È ·½
·½ let signal Þ ·½´ µ È until in
let snapshot x È until in
È until
Now we can inspect the sizes of the new programs:
¬
¬È½
½
¬
¬ ¿ · × until · let snapshot x × until in × until
¿ · ´½ · × µ · ´¾ · × until · × until µ
¿ · ´½ · × µ · ´¾ · ¾ ¡´½ · × µµ
· ¿ ×
¬
¬È½
·½
¬
¬ · ¿ È
· · ¿ ×
Therefore for all ¾ÆÑ,
È½
· ¿ ×
We also have that for all ¾ÆÑ ½ and ¾Æ ,
¬
¬È ·½
·½
¬
¬ ¿ · È until ·
¬
¬let snapshot x È until in È until
¬
¬
¿ · ´½ · È µ · ´¾ ·
¬
¬È until
¬
¬ ·
¬
¬È until
¬
¬µ
¿ · ´½ · ¾¾ · × µ · ´¾ · ¾ ¡´½ ·
¬
¬È
¬
¬µµ
¾¾ · · × · ¾
¬
¬È
¬
¬
59

Therefore,
ÈÑ
Ñ ¾¾Ñ ½ · × · ¾
¬
¬ÈÑ ½
Ñ ½
¬
¬
¾¾Ñ ½ · × · ¾ ¡´¾¾´Ñ ½µ ½ · × · ¾
¬
¬ÈÑ ¾
Ñ ¾
¬
¬µ
...
¾
Ñ ½
¬
¬È½
½
¬
¬ · ¦
Ñ ¾
¼ ¾ ´¾¾´Ñ µ ½ · × µ
¾
Ñ ½
¬
¬È½
½
¬
¬ · ´¾¾Ñ ½ · × µ ¡¦
Ñ ¾
¼ ¾ ¦
Ñ ¾
¼ ¡¾
¾
Ñ ½´ · ¿ × µ · ´¾¾Ñ ½ · × µ ¡´¾
Ñ ½ ½µ ¦
Ñ ¾
¼ ¡¾
Let ¦
Ñ ¾
¼ ¡¾ , we have
¾
¦
Ñ ¾
¼ ¡¾
·½ ¦
Ñ ¾
¼ ¡¾
¦
Ñ ½
½ ´ ½µ ¡¾ ¦
Ñ ¾
¼ ¡¾
¦
Ñ ½
½ ´ ½µ ¡¾ ¦
Ñ ¾
½ ¡¾
´Ñ ¾µ ¡¾
Ñ ½ · ¦
Ñ ¾
½ ´ ½ µ ¡¾
´Ñ ¾µ ¡¾
Ñ ½ ¦
Ñ ¾
½ ¾
´Ñ ¾µ ¡¾
Ñ ½ ´¾
Ñ ½ ¾µ
´Ñ ¿µ ¡¾
Ñ ½ · ¾
Hence,
ÈÑ
Ñ ¾
Ñ ½´ · ¿ × µ · ´¾¾Ñ ½ · × µ ¡´¾
Ñ ½ ½µ ¦
Ñ ¾
¼ ¡¾
¾
Ñ ½´ · ¿ × µ · ´¾¾Ñ ½ · × µ ¡´¾
Ñ ½ ½µ ´´Ñ ¿µ ¡¾
Ñ ½ · ¾µ
¾
Ñ ½´´ · ¿ × µ · ´¾¾Ñ ½ · × µ ´Ñ ¿µµ ´´¾¾Ñ ½ · × µ · ¾µ
¾
Ñ ½´¾½Ñ ¿ · × µ ¾¾Ñ · ½¾ ×
¾
Ñ ½´¾½Ñ · µ ¾¾Ñ · ½¼
In other words, after Ñ steps of execution, the program ÈÑ grows to size ¾
Ñ ½´¾½Ñ· µ
¾¾Ñ · ½¼, which is exponential with respect to Ñ. Since ÈÑ is linear with respect to Ñ,
60

we know that ÈÑ
Ñ is indeed exponential with respect to ÈÑ .
However, although the worst case is exponential, we only expect to see it in contrived
examples. For a normal program, our experience is that the upper bound is linear or close
to linear to the size of the program.
3.6 Expressiveness
To prevent unlimited memory usage, synchronous data-flow reactive languages [52, 18, 7,
5] adopt the model that all signals are statically allocated: the number of active signals re-
mains fixed through the lifespan of the system. This over-simplification makes it difficult
to express systems that change modes dynamically, where the system performs different
tasks in different modes.
To address this problem, the language Synchronous Kahn Networks [8] was proposed.
This language basically extends LUSTRE with recursive switching and higher-order func-
tions. When a signal switches from one mode to another, new local signals can be in-
troduced, hence breaking the static allocation limit. However, unwise use of this feature
may cause the number of signals to keep growing, rendering this language unsuitable for
real-time systems. FRP allows general recursion, and therefore does not match the need
for developing real-time reactive systems either.
We have shown that RT-FRP programs are bounded in space and time consumption,
yet RT-FRP still allows certain (restricted) forms of recursion. This is an improvement
over existing languages. In particular, compared with synchronous data-flow reactive
languages, expressing finite automata is much easier and more natural in RT-FRP. We will
present a scheme for encoding arbitrary finite automata, and use a cruise control system
as an example.
61

3.6.1 Encoding finite automata
Let Å be a finite automaton with Ò states Þ½ ¡¡¡ ÞÒ, where Þ½ is the start state. When
the system is in state Þ (where ¾ ÆÒ), it behaves like × . From state Þ , there are Ñ
out-going transitions: when event Ú occurs (where ¾ ÆÑ ), Å jumps from state Þ to
Þ . Such is a generic description of a finite automaton. This automaton can be expressed
in RT-FRP as
let signal Þ½´ µ ×½ until Ú½ µÞ½
¾ÆÑ½
...
ÞÒ´ µ ×Ò until ÚÒ µÞÒ
¾ÆÑÒ
in ×½ until Ú½ µÞ½
¾ÆÑ½ .
Actually, RT-FRP is capable of encoding generalized finite automata where each state
is parameterized by a variable whose value is determined by a run-time event:
let signal Þ½´Üµ ×½ until Ú½ µÞ½
¾ÆÑ½
...
ÞÒ´Üµ ×Ò until ÚÒ µÞÒ
¾ÆÑÒ
in ×½ Ü Ú until Ú½ Ü Ú µÞ½
¾ÆÑ½ .
3.6.2 Example: a cruise control system
As an example of encoding a finite automaton, we develop a simplified cruise control
system for an automobile. The user can manipulate the system using three events: × Ø,
Ñ Ö , and Ò Ð. The system can be in one of the three states: Off, Ready, and On. The
output of this system is either Nothing (if the cruise control is not active or the user hasn’t
set the desired speed yet) or Just Ö (if the cruise control is active and the user has set the
desired speed to Ö). The state-transition diagram for this system is shown below:
62

Off
Ready
On
set mark
start
cancel
mark
cancel
Initially the system is in the Off mode. It enters the Ready mode when the user presses
the × Ø button. However, in this mode the output is still Nothing. The user can then fire the
Ñ Ö event, which carries a real number, to notify the system of the desired speed. Once
a Ñ Ö event is fired, the system enters the On mode, and the desired speed is set to the
occurrence value of Ñ Ö . The user can change the desired speed whenever he feels like
it by firing consequent Ñ Ö events. The user can turn off the cruise control (i.e. return
the system to the Off mode) at any time by pressing the Ò Ð button.
As we have shown, modes in controllers can easily be mapped to a let-signal construct
in RT-FRP. Following the scheme we presented in the previous section, we can encode this
controller (with suitable definitions for × Ø, Ñ Ö , and Ò Ð) as
let signal Off´ µ éxt Nothingµ until × Ø µReady
Ready´ µ éxt Nothingµ until Ñ Ö µOn
Ò Ð µOff
On´xµ éxt ´Just xµµ until Ñ Ö µOn
Ò Ð µOff
in éxt Nothingµ until × Ø µReady .
63

3.7 Syntactic sugar
It may be surprising to a reader familiar with FRP that some of its basic constructs are
missing in RT-FRP. Many of these constructs, however, are definable in RT-FRP. By keep-
ing the RT-FRP language simple and defining features as syntactic sugar, we have made
the study of its resource-boundedness property tractable.
This section extends the RT-FRP language with some convenient syntactic sugar. In
what follows, we use the notation for the de-sugaring function that turns a sugared
program into a plain RT-FRP program.
3.7.1 Lifting operators
We can define the lifting operators such as:
lift0 ext
lift1 ´ Ü µ × let snapshot Ü × in ext
lift2 ´ ´Ü½ Ü¾µ µ ×½ ×¾ let snapshot Ü½ ×½ in
let snapshot Ü¾ ×¾ in ext
and so on. We also allow the user to simplify
liftÒ ´ ´Ü½ ¡¡¡ ÜÒµ ´Ü½ ¡¡¡ ÜÒµµ ×½ ¡¡¡ ×Ò
further to
liftÒ ×½ ¡¡¡ ×Ò
Those familiar with -calculus will recognize that this is just -conversion.
To illustrate, suppose we wish to define a signal representing the current time in min-
64

utes. We can do this by:
let snapshot t time in ext ´t ¼µ
or more concisely with the lift1 syntactic sugar:
lift1 ´ x x ¼µ time
To compute externally with more than one signal, we have to snapshot each one sep-
arately. For example, the term:
let snapshot x ×½ in
let snapshot y ×¾ in ext ´x · yµ
is a signal that is the point-wise sum of the signals ×½ and ×¾. We can rewrite it using lift2
as
lift2 ´ ´x yµ x · yµ ×½ ×¾
or more concisely
lift2 ´·µ ×½ ×¾
3.7.2 Some stateful constructs
As another example, the when operator in FRP turns a Boolean signal × into an event that
occurs whenever × transitions from false to true. This useful operator can be deﬁned using
delay:
when × let snapshot Ü½ × in
let snapshot Ü¾ delay False ´ext Ü½µ in
ext ´ Ü¾ Ü½µ
where Ü½ and Ü¾ are fresh variables.
65

A particularly useful stateful operation that we can express in RT-FRP is integration
over time, defined below using the forward-Euler method:
integral × let snapshot Ú × in
let snapshot t time in
let snapshot st delay ´¼ ¼ ¼µ
éxt ćase st of í0 v0 t0µ µí0 · v0 ¡´t t0µ v tµµµ
in ext ćase st of í µ µiµ
where Ú is a fresh variable.
Note that the internal state of integral × is a tuple ´ Ú Øµ, where is the running inte-
gral, Ú is the previous value of ×, and Ø is the previous sample time.
In addition, FRP’s never and once operators generate event values that never occur
and occur exactly once, respectively. They can be expressed in RT-FRP as follows:
never ext Nothing
once × let snapshot Ü × in
let snapshot occ delay False
éxt ćase Ü of Just µTrue else occµµ in
ext íf occ then Nothing else Üµ
where Ü is fresh.
FRP’s till operator, similar to the until construct in RT-FRP, can be translated as fol-
lows:
×½ till Ú µ Ü ×¾ let signal Þ´Üµ ×¾ until
in ×½ until Ú µÞ
where Þ is fresh.
66

3.7.3 Pattern matching
It is usual for functional languages to use pattern matching in definitions. For example, it
is more convenient to write
let snapshot ´x yµ ×
in ext ´x · yµ
than
let snapshot z ×
in ext ćase z of ´x yµ µx · yµ.
Standard techniques for translating definitions using pattern matching to pattern-
matching-free definitions can be applied to RT-FRP programs.
3.7.4 Mutually recursive signals
The let-snapshot construct in RT-FRP defines a self-recursive signal. But what about mutu-
ally recursive signals?
It turns out that mutually recursive signals can be expressed as syntactic sugar in RT-
FRP, as long as the base language has tuples. For example, to define two signals ×½ and ×¾
that depend on each other, we may want to use the syntax:
let snapshot Ü½ ×½
Ü¾ ×¾
in ×
where Ü½ and Ü¾ can both occur free in ×½, ×¾, and ×.
The translation of the above definition into RT-FRP can be:
67

let snapshot ´Ü½ Ü¾µ let snapshot Ý½ ×½ in
let snapshot Ý¾ ×¾ in
ext ´Ý½ Ý¾µ
in ×
where Ý½ and Ý¾ are two fresh variables.
In general, a group of Ò mutually recursive deﬁnitions:
let snapshot Ü½ ×½
Ü¾ ×¾
...
ÜÒ ×Ò
in ×
can be rewritten as:
let snapshot ´Ü½ Ü¾ ÜÒµ let snapshot Ý½ ×½ in
let snapshot Ý¾ ×¾ in
...
let snapshot ÝÒ ×Ò in
ext ´Ý½ Ý¾ ÝÒµ
in ×
where Ý½, Ý¾, . . . , ÝÒ are Ò fresh variables.
As an example, we deﬁne a pair of signals that at each instant both get the value of the
other signal from the previous instant:
68

let snapshot x delay ¼ éxt yµ
y delay ½ éxt xµ
in éxt xµ
which is then de-sugared to:
let snapshot ´x yµ let snapshot x1 delay ¼ éxt yµ in
let snapshot y1 delay ½ éxt xµ in
ext ´x1 y1µ
in éxt xµ.
3.7.5 Repeated switching
FRP has a switch construct that repeatedly switches into a signal when certain events
occur. It is possible to define switch in terms of let-signal and until as:
× switch on Ü Ú in × let snapshot Ý Ú in
let signal Þ ´Ü µ × until ext Ý µÞ
in × until ext Ý µÞ
where Ý and Þ are fresh.
3.7.6 Optional bindings
The let-signal construct allows each signal to be parameterized by a base language vari-
able. When the parameter is not used, we allow the user to omit it.
Recall the cruise control system in Section 3.6.2:
69

let signal Off´ µ éxt Nothingµ until × Ø µReady
Ready´ µ éxt Nothingµ until Ñ Ö µOn
Ò Ð µOff
Ò Ð µOff
In the definitions of Off and Ready, we do not actually use the formal parameter.
Therefore, we allow the user to instead write
let signal Off éxt Nothingµ until × Ø µReady
Ready éxt Nothingµ until Ñ Ö µOn
Ò Ð µOff
Ò Ð µOff
In the expression
×½ switch on Ü × in ×¾
Ü is in scope in ×¾, and is bound to the occurrence value of the event ×. However, often ×¾
is not interested in this value, and there is no need to give it a name. If this is the case, we
can write the expression as
×½ switch on × to ×¾
3.7.7 Direct use of signal variables
Looking at the cruise control example again, we notice that the body of the definition
éxt Nothingµ until × Ø µ Ready simply repeats the definition for the Off signal vari-
able. While the intention of the programmer is such that “initially the system is in the
70

Off mode”, RT-FRP does not allow the user to directly write so. The purpose of such
restriction is to simplify the semantics.
We can let the user use signal variables directly in his program, and then inline the
definition before execution. For example, using the Off signal variable directly, one can
rewrite the cruise control system in a simpler form:
let signal Off éxt Nothingµ until × Ø µReady
Ready éxt Nothingµ until Ñ Ö µOn
Ò Ð µOff
Ò Ð µOff
in Off.
As another example, the sample-and-hold register with initial value ¼, which we de-
fined in Section 3.1, can be written as
let signal hold´xµ éxt xµ until × ÑÔÐ µhold
in hold´¼µ.
3.7.8 Local definitions in the base language
In RT-FRP, even if the base language supports local definitions, such definitions cannot
be shared across expression boundaries. If we want to use a base language definition in
more than one base language expression, we have to look for new ways. For example, in
let snapshot z
ext ´sin´x · ¼µµ until ext ´sin´x · ¼µ ¼ µ µ×½
in éxt zµ
71

the computation of z contains two copies of the sin´Ü· ¼µ, which is not optimized. If we
define the syntactic sugar
let Ü in × let snapshot Ü ext in ×
where Ü ¾ Î ´ µ, then we can write the above program fragment as
let y sin´x · ¼µ in
let snapshot z éxt yµ until ext ý ¼ µ µ×½
in éxt zµ.
Chapter summary
RT-FRP improves over synchronous data-flow reactive languages by allowing restricted
recursive switching, which makes it easy to directly express arbitrary finite automata.
A type system ensures that RT-FRP programs are resource-bounded even with recur-
sion. The space and time complexity of executing a program is exponential with respect
to its size in the worst case. For normal programs, our experience is that the complexity is
linear or close to linear. With some syntactic sugar, much of the functionality in FRP can
be regained in RT-FRP.
72

Chapter 4
Hybrid FRP
Many reactive systems are hybrid in the sense that they contain both discrete and continu-
ous components. Discrete components are those that change states and interact with other
components in steps, for example a switch or a clock; in contrast, continuous components,
for example a speedometer or a numeric integrator, can change states or interact with
other components continuously (i.e. at any point in time). Reactive programs embedded
in continuously changing environments are examples of hybrid systems.
RT-FRP can be used to program such hybrid systems by representing continuous com-
ponents by their samples. For example, although we are unable to know the reading of
the speedometer at all times, we can sample it at every second. The samples then can be
treated by RT-FRP as a signal. Of course, not all information from the continuous read-
ing is present here, but if once per second is not good enough, we expect the program to
generate better results by increasing the sampling rate to five times per second, and so on.
Still, this approach of relying on explicit sampling is not satisfactory. The study of
high-level programming languages is about abstraction: we are not content with just find-
ing a way to get the work done; rather, we would like to find the way that concerns us
with the least amount of uninteresting details and artifacts. Abstraction helps the pro-
grammer to concentrate on the essence of the problem, and makes it less likely to make
low-level mistakes. Anyone who has programmed in assembly languages knows how
73

distracting it can be to have to consider all the low-level details at all times.
A continuous component can be most naturally abstracted as a function from time,
not a sequence of time-stamped values. And we want the programmer to be able to for-
get that he is sampling the continuous component. Unfortunately, RT-FRP has a discrete
step semantics, and therefore fails to describe continuous components naturally. To use
such a component, an RT-FRP programmer has to “discretize” it explicitly using sampling
techniques. There are two problems in particular with this approach:
1. Sampling is an artifact of the limit of the programming language, and distracts the
programmer from solving the problem.
2. For a hybrid system implemented using sampling, we would expect it in general
to yield more accurate results as we increase the sampling rate. Formally, in the
idealized situation where the sampling intervals approach zero, the output of the
system should converge to some stable behavior. However, RT-FRP does not guar-
antee this and makes bugs in this nature hard to spot. For example, the following
valid RT-FRP program À ÖØ Ø:
let snapshot x delay ¼ ext ´x · ½µ in ´ext xµ
counts the “heartbeats” of the system, and does not converge to anything as we
increase the sampling rate.
To alleviate these problems, we provide a level of abstraction that hides the details of
RT-FRP’s sampling. This abstraction is captured in a language H-FRP (for Hybrid FRP)
whose constructs can be easily deﬁned in terms of RT-FRP. H-FRP is designed such that
certain combinations of RT-FRP constructs (for example the above program) are not al-
lowed, thus making it less likely to write programs that diverge as the sampling rate
increases.
Although H-FRP is not as expressive as RT-FRP, it may still be preferred when pro-
74

gramming hybrid reactive systems. The reason is two-fold: first, although it is true that
we cannot express certain RT-FRP programs in H-FRP, most of such programs are “junk”
in the setting of hybrid systems, À ÖØ Ø being one example. Thus, being unable to
write them is actually a good thing. Second, although sometimes we miss the expressive-
ness of RT-FRP, by programming in H-FRP, the programmer does not need to be con-
cerned with sampling, and can pretend he is dealing with continuous signals. This makes
the gap between the model and presentation narrower and helps to reduce the number of
bugs introduced while translating the specification to the program.
4.1 Introduction and syntax
In RT-FRP, a signal of type “Maybe «” is used as an event that generates values of type
«. There is no clear distinction between a behavior and an event: the latter is just a spe-
cial case of the former. A syntactic distinction between behaviors and events is therefore
unnecessary.
In H-FRP, a behavior and an event are decidedly different and cannot be confused: the
former represents a continuous-time signal and can be viewed as a function on time, while
the latter is a possible event occurrence and can be thought of as an optional time-stamped
value.1 Therefore, in H-FRP we distinguish events and behaviors in the syntax.
As in RT-FRP, H-FRP has a switching construct where a behavior can become active
(be switched into) when an event occurs. Therefore, in an H-FRP program, while some
behaviors are started at time 0 (when the system starts), some might start later. In general,
the current value of a behavior depends not only on the current time, but also on when it
was started, as in the case of integration. Therefore, a more precise intuition of a behavior
should be a function from the start time and the current time to a value. Similarly, we
should view an event as a possible occurrence between the start time and the current
1
Those familiar with FRP might remember that FRP events are time-ordered sequences of occurrences,
while here we view H-FRP events as single occurrences. We make this simplification to improve the presen-
tation of our ideas. The reader should be assured that there is no technical difficulty to extend H-FRP events
to multi-occurrences.
75

time.
The abstract syntax of H-FRP is defined in Figure 4.1. As in RT-FRP, is still the base
language expression.
Behaviors ¿ input
¬
¬ time
¬
¬ lift ´ ´Ü½ ¡¡¡ ÜÒµ µ ½ ¡¡¡ Ò
¬
¬
integral
¬
¬ let behavior Þ ´Ü µ Û in
¬
¬ Û
Switchers Û until Ú µÞ
Events Î ¿ Ú when
¬
¬ liftev ´ ´Ü¼ ¡¡¡ ÜÒµ µ Ú ½ ¡¡¡ Ò
Figure 4.1: Syntax of H-FRP
As in RT-FRP, input and time are still the two primitive behaviors, the former being
the system input signal and the latter being the time. The lift operator applies a function
in the form of ´Ü½ ¡¡¡ ÜÒµ pointwise to Ò behaviors, and the result is one behavior.
integral is a Real-typed behaviors that is the integral of behavior . let-behavior is
analogous to RT-FRP’s let-signal and defines a group of behaviors that can switch into
each other. A switcher Û is a behavior that switches to other behaviors when some events
occur.
An event can have two forms: a predicate event when that occurs when the Boolean
behavior changes from False to True, or a liftev construct that applies a function to the
value of an event and the current values of some behaviors when occurs. liftev is a
generalization to both of FRP’s event mapping (the µoperator) and event snapshot (the
snapshot combinator).
Since the only way to use an event Ú in a behavior is to reference either Ú or some
event built from Ú using liftev to trigger a switch, only the first occurrence of Ú can have
an impact on the program execution. This justifies our modeling an event as a potential
single occurrence. Had H-FRP supported some constructs that make use of multiple oc-
currences of an event, for example switch, we would have to change the denotation of an
76

event to a time-ordered sequence of values, but this change is easily accommodated.
In the lift and liftev constructs, Ò can be any integer greater than or equal to ¼. We
adopt the convention of writing “ Ü ” for “ ´Üµ ” when Ò ½, and writing “ ” for
“ ´µ ” when Ò ¼. Hence
lift True lift ´x x · ½µ time and lift ´ ´x yµ x · yµ ½ ¾
are all syntactically valid behavior expressions.
The integral construct is particularly useful, as many hybrid systems are deﬁned using
integral equations. In particular, hybrid automata [22] are deﬁned as mode switching
machines where inside each mode, the behavior of the system is described by its rate of
change. Hence the system state within a mode is obtained by integrating over its change
rate. Being able to express integration over time directly allows us to implement such
systems more naturally.
As with RT-FRP, we require that all behavior variables have distinct names. A program
that reuses names can easily be made to conform with our requirement by renaming those
offending variables.
4.2 Type system
The type system of H-FRP is basically the same as that of RT-FRP, except that events and
behaviors now belong to different type families. The type system is actually simpler than
that of RT-FRP, since H-FRP does not have the recursive let-snapshot construct.
4.2.1 Contexts
The typing of a behavior or event is done in two contexts:
¯ the variable context which maps base language variables to types, and
77

¯ the behavior context ª which assigns argument types and result types to behavior
variables.
The definition of is the same as in Section 2.2, and ª is defined as:
ª Þ « «¼
4.2.2 Typing judgments
The type system of H-FRP can be defined using two typing judgments:
¯ ª B «: “ is a behavior of type « in context and ª;” and
¯ ª Ú E «: “ Ú is an event of type « in context and ª.”
The reader can find the complete typing rules in Figure 4.2, which are straightforward
for the most part:
The two primitive behaviors input and time have type B Input and B Real respec-
tively, where Input is a placeholder for the actual input to the system.
The nullary lifting operation lift turns a base language expression of type « into a
behavior of type B «. The unary lifting lift ´ Ü µ builds a behavior of type B «¼, where
is a B « and Ü is a function from « to «¼. Lifting operations of higher arities are typed
similarly.
The integral operator only works on Real behaviors, and returns a Real behavior.
Let-behavior defines a mutually recursive group of behaviors, each parameterized
by a base language variable. The corresponding typing rule reflects that the behavior
variables can occur free in their definitions as well as the body of let-behavior.
In until Ú µÞ , and Ú cannot contain free behavior variables.
The predicate event operator when turns a behavior of Bool to an event of the unit
type.
liftev ´ ´Ü¼ ¡¡¡ ÜÒµ µ Ú ½ ¡¡¡ Ò is an event of type «, where Ú is an «¼ event, ½,
. . . , Ò are behaviors of type «½, . . . , «Ò respectively, and ´Ü¼ ¡¡¡ ÜÒµ is a function from
78

´«¼ «½ ¡¡¡ «Òµ to «.
ª B «
ª input B Input ª time B Real
ª B «
Ü « «
ª lift ´ ´Ü½ ¡¡¡ ÜÒµ µ ½ ¡¡¡ Ò B «
ª B Real
ª integral B Real
¨ Ü « ª
¼ Û «¼ ¾Â
ª
¼ B « ª
¼ ª ¨ Þ « «¼ ¾Â
ª let behavior Þ ´Ü µ Û ¾Â in B «
B « Ú E «
ª Þ « « until Ú µ Þ B «
ª Ú E «
ª B Bool
ª when E ´µ
ª Ú E «¼ ª B « ¾ÆÒ
¨ Ü « ¾ ¼ Ò «
ª liftev ´ ´Ü¼ ¡¡¡ ÜÒµ µ Ú ½ ¡¡¡ Ò E «
Figure 4.2: Type system of H-FRP
4.3 Denotational semantics
Next, we give a denotational semantics to H-FRP by deﬁning two semantic functions:
at for behaviors and occ for events. We will also need an auxiliary function eval
to evaluate a base language term.
79

4.3.1 Semantic functions
To define the semantic functions, we need to introduce the following notations:
¯ (read “ lifted”) stands for the set obtained by adding the bottom element to set
, i.e.
def
¯ Ú is the syntactic category for optional values:
Ú Ú
¬
¬
¯ is a behavior environment, which maps behavior variables to their definitions:
¿ Þ Ü Û
¯ and is a lifted variable environment, which maps variables to optional values:
¿ Ü Ú
The signatures of the semantic functions can then be given as:
at Ì Ì Î
occ Î Ì Ì ´Maybe ´Ì Î µµ
eval Î
The function at takes a behavior term , a behavior environment that defines
all free behavior variables in , a start time Ø¼, and a current time Ø that satisfies Ø Ø¼.
It returns the value of (which was started at time Ø¼) at time Ø. Note that the result
has type Î rather than Î . The reason is that, just like the standard practice of using
“bottom” ( ) to denote abnormal situations (programs that generate run-time errors or
80

do not terminate, for example) in denotational semantics, we need something to denote
run-time anomaly of an H-FRP program.
However, we must emphasize that one is not to equate the bottom element in H-FRP to
that in traditional work on denotational semantics, for there is a major difference between
the two: the bottom element ( ) here does not denote run-time error or non-termination.
Instead, it just means “no information.” For example, at Ø¼ Ø simply means that
the value of behavior , starting at time Ø¼, at time Ø is unspecified. This unusual interpre-
tation of might be surprising at first, but since H-FRP is for real-time systems, run-time
error or non-termination is not acceptable. In fact, as we will see in Section 4.4, we can
execute an H-FRP program on a real computer by first translating it to RT-FRP, which is
then guaranteed to be resource-bounded and will never generate run-time errors.
As we have said in Section 4.1, events in H-FRP can have only one occurrence. The
function occ gives meaning to an event term Ú. Its arguments include Ú, a behavior
environment that defines all free behavior variables in Ú, a start time Ø¼, and a current
time Ø. It returns Nothing if Ú hasn’t occurred since Ø¼ up to Ø, or Just ´ Úµ if Ú occurred
at time ¾ Ø¼ Øµ with value Ú. It may also return if there is not enough information to
determine an occurrence or the absence of it.
Finally, the auxiliary function eval evaluates a base language term . It takes a
lifted environment , which may map a variable to , strips of those mappings
leading to , and then evaluates in this stripped-down environment . If does not
contain enough information to evaluate (for example, when maps a free variable in
to ), will be returned.
eval eval
Ú
Ú ¸ Ú where Ü
and Ü Ú
otherwise
81

4.3.2 Environment-context compatibility
Naturally, when studying the semantics of a behavior term in environment , we would
only use a that “makes sense” to . For example, the term
´lift ¼µ until Ú µz
is meaningless in the environment
z x lift False
because it requires to change from a numeric behavior to a Boolean behavior when Ú
occurs.
To assert that such a run-time type error never occurs, we need the following concept:
Definition 4.1 (Environment-context compatibility). A behavior environment Þ
Ü Û ¾ÆÒ is compatible with behavior context ª, if ª ª
¼ Þ « «¼ ¾ÆÒ , and
¾ÆÒ Ü « ª Û B «¼ . We denote this symbolically by
ª
The intuition behind this concept is not difficult. A behavior context ª assigns types
to behavior variables, and a behavior environment defines behavior variables. When
we say is compatible with ª, we expect for all Þ defined in , it has a type in ª, and its
definition in has the same type.
Note that since we are only interested in behavior environments where all definitions
are closed, we do not need to talk about a variable context when we discuss the com-
patibility of with ª.
82

4.3.3 Definition of at and occ
In defining the semantics of H-FRP, and in the rest of the chapter, we assume that there is
a global function named “ ÒÔÙØ”, which has type Ì Input and specifies the input to the
system at any given time. Hence, the meaning of a program is parameterized over this
function.
The denotational semantics of well-typed closed H-FRP terms is given in Figure 4.3
and Figure 4.4, where we require Ø Ø¼, and
Ê
is the Riemann integral extended to func-
tions that might return at a finite number of points:
Ø
Ø¼
´ µ
Ê Ø
Ø¼
¼´ µ
´ µ on Ø¼ Ø except a finite set Ë Ì
¼´ µ
def
if ´ µ then ¼ else ´ µ
otherwise
and the Ñ Ô function is defined as:
Ñ Ô ´« «¼µ ´Maybe «µ ´Maybe «¼µ
Ñ Ô
Ñ Ô Nothing Nothing
Ñ Ô ´Just Úµ Just ´ Úµ
The semantics of when is particularly involved. To help the reader gain an intuition,
we illustrate it in Figure 4.5, 4.6, and 4.7. In particular:
1. Figure 4.5 shows the general case and two special cases where when has no occur-
rence on Ø¼ Øµ. A solid round end of a line segment emphasizes that the value of the
behavior at that point is significant, while a normal end means that the value of
at that end is irrelevant. For example, part ´ µ of the figure should be interpreted as:
is True on Ø¼ Ì½µ, False on ´Ì½ Øµ, and we do not care about ’s value at Ì½ and Ø;
part ´ µ means: is False on ´Ø¼ Øµ, and its value at Ø¼ or Ø is not important; and so
83

at
at input Ø¼ Ø ÒÔÙØ´Øµ
at time Ø¼ Ø Ø
at lift ´ ´Ü½ ¡¡¡ ÜÒµ µ ½ ¡¡¡ Ò Ø¼ Ø eval Ü at Ø¼ Ø
at integral Ø¼ Ø
Ê Ø
Ø¼
´at Ø¼ µ
at let behavior Þ ´Ü µ Û in Ø¼ Ø at Þ Ü Û Ø¼ Ø
at until Ú µÞ ¾ÆÒ Ø¼ Ø
at Ø¼ Ø ¾ÆÒ Ó ´Øµ Nothing
at Û Ü Ú Ø
Ì ¾´Ø¼ Ø Ó ´Ìµ Just ´ Úµ Ü Û ´Þ µ
and ¾ÆÒ Ó ´Ìµ Nothing
otherwise
where Ó ´Øµ occ Ú Ø¼ Ø
Figure 4.3: Denotational semantics of behaviors
84

occ Ú
occ when Ø¼ Ø
Nothing
Ì½ ¾ Ø¼ Ø Ø¼ Ì½ µ ´ µ True, and
Ì½ Ø µ ´ µ False
Just ´Ø¼ ´µµ
´Ø¼µ False, and Ì½ ¾´Ø¼ Ø
¾´Ø¼ Ì½ µ ´ µ True
Just ´Ì¾ ´µµ
Ì½ Ì¾ Ì¿ Ø¼ Ì½ Ì¾ Ì¿ Ø
¾ Ø¼ Ì½µ ´Ì¾ Ì¿ µ ´ µ True
and ¾´Ì½ Ì¾µ µ ´ µ False
otherwise
where ´ µ at Ø¼
occ liftev ´ ´Ü¼ ¡¡¡ ÜÒµ µ Ú ½ ¡¡¡ Ò Ø¼ Ø
Ñ Ô ´ Úµ ´ eval Ü¼ Ú Ü at Ø¼ ¾ÆÒµ ´occ Ú Ø¼ Øµ
Figure 4.4: Denotational semantics of events
85

on.
2. Figure 4.6 shows the cases where when occurs on Ø¼ Øµ. An upward arrow is used
to indicate the time of the occurrence, and a hollow circle in a line segment means
the value of at that point is not the same as that at the other points in the segment.
For example, part ´ µ of the ﬁgure means that when occurs at time Ø¼ if is False
at Ø¼ and True on ´Ø¼ Ì½µ.
3. Figure 4.7 illustrates that when there is a glitch in , either negative or positive, we
do not know whether when occurs on Ø¼ Øµ.
Finally, we point out that H-FRP is type preserving in the following sense:
Lemma 4.1 (Type preservation of semantics). Given any ¾ , Ú ¾ Î , ¾ , and
type «, we have
1. ª B « and ª µ Ø¼ Ø ¾Ì at Ø¼ Ø ¾« , and
2. ª Ú E « and ª µ Ø¼ Ø ¾Ì occ Ú Ø¼ Ø ¾´Maybe ´Ì «µµ .
Proof. By co-induction on the derivation trees for ª B « and ª Ú E «.
4.4 Operational semantics via translation to RT-FRP
Although we now have a denotational semantics for H-FRP, we cannot derive an imple-
mentation from it yet. The reason is that the semantics uses some continuous operations
not available for digital computers, for example, Riemann integral and search over a con-
tinuum of real numbers (the latter is used in the semantics of the until construct).
To guide the implementation, we give an operational semantics to H-FRP in this sec-
tion. Although we could come up with a direct operational semantics, we choose to in-
stead present a translation from H-FRP to RT-FRP, and then use the operational semantics
of RT-FRP to execute the target program. We have two reasons for doing this:
86

False
True
time
t0
tT1
(a). general case (Ø¼ Ì½ Ø)
False
True
t0
t
time
(b). Ø¼ Ì½
False
True
time
t0
t
(c). Ì½ Ø
Figure 4.5: Semantics of when: no occurrence
87

False
True
time
t0
tT1
(a). Immediate occurrence
False
True
time
t0
tT1
T2
T3
(b). Late occurrence: general case
False
True
time
t0
tT2
T3
(c). Late occurrence: special case (Ø¼ Ì½)
Figure 4.6: Semantics of when: occurrence
88

False
True
time
t0
tT1
T2
(a). Negative glitch (Ø¼ Ì½ Ì¾ Ø)
False
True
time
t0
tT1
T2
(b). Positive glitch (Ø¼ Ì½ Ì¾ Ø)
Figure 4.7: Semantics of when: not enough information
89

1. This approach involves less work than defining a direct operational semantics; and
2. By having such a translation, we clearly show that H-FRP can be regarded as a
subset of RT-FRP.
Figure 4.8 defines the function tr that translates H-FRP terms to RT-FRP. The definition
is syntax-directed.
Please note that, since we require that all behavior variables have distinct names in the
source program, and the translation only introduces fresh names, the let-signal clauses
obtained from translating lift are not recursive, i.e. the variables Ü cannot occur in the
terms tr .
Naturally, we expect that the translation function tr turns a well-typed H-FRP pro-
gram into a well-typed RT-FRP program. In addition, we expect that an H-FRP behavior
of type « is translated to a signal of the same type, and an H-FRP event of type « is trans-
lated to a signal of type Maybe «. This property is formalized by the following lemma:
Lemma 4.2 (Type preservation of translation). For all variable contexts and ¢, signal
context ª, and terms and Ú, we have
1. ª B « µ ¢ ¡ S tr «, and
2. ª Ú E « µ ¢ ¡ S tr Ú Maybe «.
Proof. The proof of this lemma is a co-induction on the derivation trees of ª B «
and ª Ú E «.
4.5 Convergence of semantics
We have shown that an H-FRP program can be translated to an RT-FRP program, which
can then be executed in discrete steps using the operational semantics we defined in Sec-
tion 3.2.
90

tr
tr input input
tr time time
tr lift ´ ´Ü½ ¡¡¡ ÜÒµ µ ½ ¡¡¡ Ò let snapshot Ü½ tr ½ in
...
let snapshot ÜÒ tr Ò in
ext
tr integral let snapshot Ø time in
let snapshot Ü tr in
let snapshot ´ ¼ Ü¼ Ø¼µ
delay ´¼ ¼ ¼µ
ext ´ ¼ · Ü¼ ¡´Ø Ø¼µ Ü Øµ
in ext ¼
tr let behavior Þ ´Ü µ Û in let signal Þ ´Ü µ tr Û in tr
tr until Ú µÞ tr until tr Ú µÞ
tr Ú
tr when let snapshot Ü tr in
let snapshot Ü¼
delay True ´ext Üµ
in ext ´ Ü¼ Üµ
tr liftev ´ ´Ü¼ ¡¡¡ ÜÒµ µ Ú ½ ¡¡¡ Ò let snapshot Ü tr Ú in
let snapshot Ü½ tr ½ in
...
let snapshot ÜÒ tr Ò in
ext ´case Ü of Just Ü¼ µJust
else Nothingµ
tr ª
tr Þ Ü Û Þ Ü tr Û
Figure 4.8: Translation from H-FRP to RT-FRP
91

Normally, when we give semantics to a language in more than one way, we expect
those semantics to “agree with each other” in the sense that they will always predict
the same result given the same input to the program. However, this is not the case for
H-FRP, as its denotational semantics implies we can always update the system state in in-
finitesimal time, while its operational semantics says the state is only updated in discrete,
countable, steps. Therefore, the denotational semantics describes the idealized situation
where we have infinite computational power.
Nonetheless, we expect some correspondence between the two semantics of H-FRP:
namely, when we execute a program using the operational semantics on an infinitely fast
imaginary computer, where the time between two execution steps is infinitesimal, we
expect the result to match that given by the denotational semantics. The rest of this section
establishes this relation under certain conditions.
4.5.1 Definitions and concepts
To formalize the relation between the two semantics, we need to define some concepts.
Time sequences and functions on them
First, we define TS as the set of time sequences, which are non-empty sequences of times in
ascending order, i.e.
TS
def
Ø½ ¡¡¡ ØÒ
¬
¬ Ò ¾Æ Ø½ ¡¡¡ ØÒ Ì and Ø½ ¡¡¡ ØÒ
Given a time sequence È Ø½ ¡¡¡ ØÒ , we often write it as ÈØ where Ø ØÒ to emphasize
that the last time in È is Ø.
The auxiliary function trace will be used to observe the sequence of values gener-
92

ated by executing an H-FRP term:
trace ´ Î µ TS Î
trace Ø½ ¡¡¡ ØÒ
def
Ú½ ¡¡¡ ÚÒ
where tr tr
Ø½ ½
¸ Ú½ ×½
Ø¾ ¾
¸ ¡¡¡ØÒ Ò
¸ ÚÒ ×Ò and ÒÔÙØ´Ø µ
Next, we define a function at , which gives the last value yielded by executing a
behavior for Ò steps:
at TS Î
at Ø× def
ÚÒ where trace Ø× Ú½ ¡¡¡ ÚÒ
and a function occ , which returns the possible occurrence of an event in its first Ò steps
of execution:
occ Î TS Maybe ´Ì Î µ
occ Ú Ø× def Nothing ¾ÆÒ ½ Ú Nothing
Just ´Ø Úµ ¾ÆÒ ½ Ú Just Ú and ¾Æ ½ Ú Nothing
where trace Ú Ø× Ú½ ¡¡¡ ÚÒ
We would like to prove that, as the sampling rate approaches infinity, at and occ
will eventually agree with at and occ , respectively. To establish such a connection,
we first need to formally define what it means by “the sampling rate approaches infinity”.
In the rest of the chapter, we will use the notation ¡Ø for Ø ·½ Ø . 2
Definition 4.2 (Norm of time sequence). Given a time sequence È Ø½ ¡¡¡ ØÒ ¾ TS,
the norm of È, written È , is defined as the maximum of the set ¼ ¡Ø ¾ÆÒ ½ . The
norm of È with respect to start time Ø¼, written È Ø¼
, is defined as Ñ Ü ¡Ø¼ È .
2
The symbol ¡ must not be interpreted as a factor but only as indicating a difference in values of the
variable which follows.
93

A metric on values
To study the limit of the operational semantics as the sampling interval goes to zero, we
need a way to measure how close two values are to each other, and we must consider
values of all types, not just real numbers. Hence, we define a metric on values as:
Definition 4.3 (Difference between values). The difference between two values Ú and Ú¼,
of the same type, written Ú Ú¼ , is the real number defined by
´µ ´µ ¼
Ö Ö¼ the absolute value of Ö Ö¼, where
“ ” is real number subtraction
´Ú½ ¡¡¡ ÚÒµ ´Ú¼
½ ¡¡¡ Ú¼
Òµ ¦
Ò
½
¬
¬
¬ Ú Ú¼
¬
¬
¬
Nothing Nothing ¼
Just Ú Just Ú¼ Ú Ú¼
Nothing Just Ú ½
Just Ú Nothing ½
It is obvious that Ú Ú¼ Ú¼ Ú and Ú Ú ¼.
94

Limit of operational semantics
Now that we have a metric on all values, we can deﬁne the limit of the operational se-
mantics when the sampling interval goes to zero as:
at
£
Ì Ì Î
at
£
Ø¼ Ø def Ð Ñ ÈØ
Ø¼
¼ at ÈØ if such limit exists
otherwise
occ£ Î Ì Ì ´Maybe ´Ì Î µµ
occ
£ Ú Ø¼ Ø def Ð Ñ ÈØ
Ø¼
¼ occ Ú ÈØ if such limit exists
otherwise
Now we can formally ask the question whether the discrete interpretation of an H-FRP
program is “faithful” to its continuous interpretation: do the following equations hold?
at
£
Ø¼ Ø at Ø¼ Ø
occ
£ Ú Ø¼ Ø occ Ú Ø¼ Ø
Or more concisely, are the following true?
at
£
at
occ
£ occ
The following section establishes this result. However, as we will see, such correspon-
dence is conditional. We will present a set of conditions that are sufﬁcient to guarantee
the correspondence. Such conditions will be made exact through a series of theorems pre-
sented in this section. We will prove that for programs satisfying this set of conditions,
the limit of the operational semantics does converge to the denotational semantics, and
will show examples of programs that do not meet such conditions and therefore whose
operational semantics do not converge to the denotational semantics.
95

Convergence and uniform convergence
We will need the following concepts in our theorems:
Definition 4.4 (¯-neighborhood). Given a real number ¯ ¼, the ¯-neighborhood of a value
Ú, written Ú ¯, is the set of values whose difference to Ú is less than ¯:
Ú ¯
def
Ü
¬
¬ Ü Ú ¯
The ¯-neighborhood of a set of values Ë, written Ë ¯, is the union of the ¯-neighborhoods of
the elements of Ë:
Ë ¯
def
Ú¾Ë
Ú ¯
Definition 4.5 (Uniform convergence). Given times Ø¼ and Ì where Ì Ø¼, a set of times
Ë, and two functions TS «, and Ì «, we say that
uniformly converges to on Ø¼ Ì except near Ë,
if for every ¯ ¼, there exists a Æ ¼ (depending only on ¯) such that for any time
sequence ÈØ where Ø Ì, Ø ¾ Ë ¯, and
¬
¬ÈØ
¬
¬
Ø¼
Æ, we have
¬
¬ ´ÈØµ ´Øµ
¬
¬ ¯
We denote this symbolically by writing
´ÈØµ ´Øµ
¬
¬Ì
Ø¼
Ë
We omit “ Ë” when Ë .
Although the definition of uniform convergence may seem daunting, the intuition is
simple: when we say a function on time sequences uniformly converges, we mean that
no matter how small the error bound we demand, we can always find a threshold Æ, such
96

that as long as the sampling interval is smaller than Æ, the result at every sample point is
guaranteed to be within the error bound.
In the above definition, we require that È Ø satisfies that Ø Ì, Ø ¾ Ë ¯, and
¬
¬ÈØ
¬
¬
Ø¼
Æ.
This condition can be rephrased more verbosely (but perhaps more understandably) as
Ø½ ¾ Ø¼ Æ, Ø½ Ø Ì, Ø ¾ Ë ¯, and
¬
¬ÈØ
¬
¬ Æ, where ÈØ Ø½ ¡¡¡ Ø .
Why are we interested in uniform convergence rather than plain convergence? After
all, why should we care about whether the convergence is uniform or not? To understand
our decision, let’s study a program called Þ ÖÖ , inspired by [3, page 401]:
Þ ÖÖ let z´t1µ ´lift ´ t let c ½ t1 in c ¡c ¡t ¡pow´½ t cµµ timeµ
until
in ´lift ¼µ until liftev ´ ´ tµ tµ
´when ´lift ´ t t ¼µ timeµµ
time
µz
Following the operational semantics of H-FRP, it is not difficult to see that
trace Þ ÖÖ Ø½ ¡¡¡ ØÒ
¼ ¼ Ú¿ Ú ¡¡¡ ÚÒ Ø½ ¼, where Ú ¾Ø´½ Øµ and ½ Ø¾
¼ Ú¾ Ú¿ ¡¡¡ ÚÒ Ø½ ¼, where Ú ¾Ø´½ Øµ and ½ Ø½
Therefore,
at
£
Þ ÖÖ ¼ ¼
Ð Ñ È¼
¼ ¼át Þ ÖÖ È¼µ
Ð Ñ È¼
¼ ¼ ¼
¼
97

and for any Ø ¾´¼ ½ , we have
at
£
Þ ÖÖ ¼ Ø
Ð Ñ ÈØ
¼ ¼át Þ ÖÖ ÈØµ
Ð Ñ ÈØ
¼ ¼´
¾Ø´½ Øµ where ÈØ Ø½ ¡¡¡ ØÒ , and
Ì if Ø½ ¼ then Ø½ else Ø¾, and ½ Ìµ
Ð ÑÌ ¼´
¾Ø´½ Øµ where ½ Ìµ
¼
Hence, we have that for all Ø ¾ ¼ ½ , at
£
Þ ÖÖ ¼ Ø ¼, and therefore
½
¼
át
£
Þ ÖÖ ¼ Øµ Ø ¼
However,
at
£
integral Þ ÖÖ ¼ ½
Ð Ñ È½
¼ ¼ ¦
Ò ½
½ Ú ´Ø ·½ Ø µ
where È½ Ø½ ¡¡¡ ØÒ ½ and trace Þ ÖÖ È½ Ú½ ¡¡¡ ÚÒ
Ð Ñ È½
¼ ¼ ¦
Ò ½
·½
¾Ø ´½ Ø µ ´Ø ·½ Ø µ ´£µ
where if Ø½ ¼ then ½ else ¾ and ½ Ø
Since
Ð Ñ
·½
½
¼
¾
Ø´½ Øµ Ø Ð Ñ
·½
¾
´ · ½µ´ · ¾µ
½
we have
´£µ ½
Therefore,
at
£
integral Þ ÖÖ ¼ ½ ½ ¼
½
¼
át
£
Þ ÖÖ ¼ Øµ Ø
98

In other words, as the sampling interval approaches ¼, the value of Þ ÖÖ at every point
in ¼ ½ eventually goes to ¼. Yet, at the same time, the area of the region under the curve
of Þ ÖÖ between time ¼ and ½ becomes ½. This is indeed counter-intuitive, and shows
that one can not purely rely on his intuition when dealing with functions on real numbers,
and that the convergence property of H-FRP programs is trickier than it may look.
This example shows that the fact that the operational semantics of a behavior con-
verges to some function does not guarantee that the operational semantics of integral
converges to
Ê
. However, as we will prove in Theorem 4.5, if the operational seman-
tics of uniformly converges to , then the operational semantics of integral will also
uniformly converge to
Ê
.
We show that the concept of uniform convergence enjoys the following form of weak-
ening:
Lemma 4.3 (Weakening of uniform convergence). If ´ÈØµ ´Øµ
¬
¬Ì
Ø¼
Ë, then for all
Ì¼ Ì and Ë¼ Ë, we have
´ÈØµ ´Øµ
¬
¬Ì¼
Ø¼
Ë¼
Proof. By the definition of uniform convergence.
Continuity and uniform continuity
To study the convergence property of lift, we will need a concept called uniform continuity
[3, page 74], as found in most treatments of calculus and analysis:
Definition 4.6 (Uniform continuity). A function is said to be uniformly continuous on a
set Ë if for every real number ¯ ¼, there exists a real number Æ ¼ (depending only on
¯) such that Ü Ý ¾Ë and Ü Ý Æ imply ´Üµ ´Ýµ ¯.
Let’s compare this concept with that of (non-uniform) continuity:
Definition 4.7 (Continuity). A function defined on Ë is said to be continuous at point
Ü ¾Ë, if for every real number ¯ ¼, there exists a real number Æ ¼ (depending only on
99

¯) such that Ý ¾Ë and Ü Ý Æ imply ´Üµ ´Ýµ ¯.
We say that is continuous on a set Ë, if is continuous at every point in Ë.
The difference between uniform continuity and continuity may be clariﬁed by the fol-
lowing analogy from [35, page 348]:
1. A man is literate if there is a language that he can read and write.
2. A group of men is literate if each of its members is literate.
3. A group of men is uniformly literate if there is one language that every member of
the group can read and write.
Here it is obvious that uniform literacy is a property not of the individuals in a group
but of the group as a whole; if each of the members of the group is literate, then it follows
that the group is literate, but not that the group is uniformly literate.
As an example of continuous but not uniformly continuous functions, ´Øµ ½ Ø is
continuous on ´¼ ½ , but not uniformly continuous on the same interval.
Please note that being uniformly continuous does not necessarily mean that the deriva-
tive is bounded. For example, ´Øµ
Ô½ Ø¾ is uniformly continuous on ¼ ½ , but
´Øµ
Ø
Ø
Ô½ Ø¾
and therefore
Ð Ñ
Ø ½
´Øµ
Ø
½
which is unbounded.
However, in the case when the domain of the function is a closed interval, continuity
does imply uniform continuity. The uniform continuity theorem is proved in [35, page 349].
Theorem 4.1 (Uniform continuity). If is continuous on , then is uniformly con-
tinuous on .
100

Note that in Deﬁnition 4.6, the function does not need to be from Ê to Ê. We only
require that there is a metric that tells us the difference between two values in the domain
(and the range) of .
Compatibility
Finally, given a well-typed and closed term , when we study its denotational semantics
at we often need to assert that is well-typed, closed, and executed in a compatible
environment , i.e. there are ª and « such that
1. ª B «, and
2. ª .
We will write
to denote this concisely.
Similarly, we write
Ú
to denote that there are ª and « such that
1. ª Ú E «, and
2. ª .
4.5.2 Establishing the convergence property
In the rest of this chapter, we assume that we can represent real numbers and carry out real
arithmetic exactly in the base language, and the sampling interval can be made arbitrarily
small. Despite existing work on computing certain operations on exact representations
of real numbers [13, 51], in general our assumption is not true, and we can only approx-
imate real numbers and functions on them. However, as Strachey pointed out [47]: “the
101

discrepancies are generally small and we usually start by ignoring them. It is only after
we have devised a program which would be correct if the functions used were the exact
mathematical ones that we start investigating the errors caused by the finite nature of our
computer.”
Our work addresses the first step suggested by Strachey (finding the values assum-
ing the operations are exact) by giving a continuous-time-based denotational semantics.
We also prove that under suitable conditions and assuming exact real operations, the er-
rors in an implementation that uses sampling to approximate continuous time approach
zero when the sampling becomes frequent enough. Therefore we also accomplish part
of the second step (investigating the errors in an implementation using approximation
techniques).
Our work is an idealized theory which provides a theoretical basis for the study of hy-
brid programming languages like H-FRP. What remains to be studied is the quantitative
relation between the errors in the output and the sampling frequency and the errors in
representation.
From now on, we will be studying the uniform convergence properties of behaviors
and events that are well-typed and closed. These properties are established by a series of
theorems. We will omit or only sketch the proof for the theorems. Complete formal proofs
can be found in Appendix A.
First, time and input uniformly converge unconditionally:
Theorem 4.2 (Time). time µ at time ÈØ Ø
¬
¬
½
Ø¼
.
Theorem 4.3 (Input). input µ at input ÈØ ÒÔÙØ´Øµ
¬
¬
½
Ø¼
.
If the function being lifted is uniformly continuous, and the sub-behaviors are all uni-
formly convergent, then the result behavior of lift is also uniformly convergent:
Theorem 4.4 (Lift). Given lift ´ ´Ü½ ¡¡¡ ÜÒµ µ ½ ¡¡¡ Ò, if we have:
1. ,
102

2. ´Ý½ ¡¡¡ ÝÒµ eval Ü Ý is uniformly continuous, and
3. ¾ÆÒ at ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë ,
then
at ÈØ eval Ü ´Øµ
¬
¬
¬
Ì
Ø¼

Ò
½
Ë
The above theorem has a particularly simple case for lifting of constants:
Corollary 4.1 (Lift0). lift µ at lift ÈØ eval
¬
¬
½
Ø¼
.
Proof. This is just the special case for Theorem 4.4 when Ò ¼.
To present Theorem 4.5 and 4.8 more concisely, we deﬁne the notation
Ø Ð Ø¼
for that either Ø Ø¼ or Ø Ø¼ ¼, where Ø Ø¼ ¾ Ì. The intuition is that we want Ø to be
smaller than Ø¼ — unless it cannot be any smaller since Ø¼ already has the smallest possible
value ¼, in which case we want Ø to be ¼ too.
We show that integral preserves uniform convergency:
Theorem 4.5 (Integral). If
1. integral ,
2. at ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë where Ë is ﬁnite, and
3. there is Ì¼ Ð Ø¼ such that
(a) for all time sequence ÈØ Ø½ ¡¡¡ Ø where Ì¼ Ø½ Ø Ì, at ÈØ is
bounded,
(b) ´Øµ is bounded on Ì¼ Ì , and
(c)
Ê Ì
Ì¼
´Øµ Ø ,
103

then we have
at integral ÈØ
Ø
Ø¼
´ µ
¬
¬
¬
¬
Ì
Ø¼
The let-behavior construct also preserves the uniform convergency of its body:
Theorem 4.6 (Let-behavior). Given let behavior Þ ´Ü µ Û in ¼, we have that
and at ¼
Þ Ü Û ÈØ ´Øµ
¬
¬
¬
Ì
Ø¼
Ë
imply that
at ¼ ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë
The switcher is more involved. Roughly speaking, if the initial behavior, the triggering
events, and the after behavior are all uniformly convergent, then the whole behavior is
uniformly convergent:
Theorem 4.7 (Until). Given ¼ until Ú µÞ ¾ÆÒ , and ,
1. if ¾ÆÒ occ
£ Ú Ø¼ Ì Nothing and at ¼ ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë, then
at ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë
2. if Ì¼ ¾´Ø¼ Ì ¾ÆÒ, such that
(a) occ£ Ú Ø¼ Ì¼ Just ´ Úµ,
(b) ¾ÆÒ occ£ Ú Ø¼ Ì¼ Nothing,
(c) at ¼ ÈØ ´Øµ
¬
¬
Ø¼
Ë,
(d) at Û Ü Ù ÈØ ´Ù Øµ
¬
¬
Ì
Ë¼, where Ü Û ´Þ µ, and
(e) ¯ ¼ Æ ¼ Ø ¾ Ì Ù Ú Æ µ ´Ù Øµ ´Ú Øµ ¯,
then
at ÈØ ´Øµ
¬
¬
Ì
´Ë Ë¼ µ
104

where ´Øµ if Ø then ´Øµ else ´Ú Øµ.
If uniformly converges, so does when :
Theorem 4.8 (When). Given Ú when and Ú , we have
1. if at ÈØ ´Øµ
¬
¬
Ì
Ø¼
, and there are Ì¼ Ì½ where Ì¼ Ð Ø¼ Ì½ Ì, such that
(a) Ì¼ Ø Ì½ µ ´Øµ True, and
(b) Ì½ Ø Ì µ ´Øµ False,
then occ
£ Ú Ø¼ Ì Nothing;
2. if there are Ì¼ Ì½ Ì¾ Ì¿ ¾Ì where Ì¼ Ð Ø¼ Ì½ Ì¾ Ì¿ Ì, such that
(a) at ÈØ ´Øµ
¬
¬
Ì¿
Ø¼
,
(b) Ø ¾ Ì¼ Ì½µ ´Ì¾ Ì¿ µ ´Øµ True, and
(c) Ø ¾´Ì½ Ì¾µ µ ´Øµ False,
then occ£ Ú Ø¼ Ì Just ´Ì¾ ´µµ.
If the function being lifted is continuous, and the event and sub-behaviors are uni-
formly convergent, then the result event of liftev is uniformly convergent:
Theorem 4.9 (Liftev). Given Ú liftev ´ ´Ü¼ ¡¡¡ ÜÒµ µ Ú¼ ½ ¡¡¡ Ò and where
Ú , write Ó for occ£ Ú Ø¼ Ì and Ó ¼ for occ£ Ú¼ Ø¼ Ì. We have
1. Ó ¼ Nothing µ Ó Nothing, and
2. if
(a) Ó ¼ Just ´ Ú¼µ,
(b) there is ¼ such that for all ¾ÆÒ,
i. at ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë where ¾ Ë , and
ii. ´Øµ is continuous at Ø ,
105

and
(c) the function ´Ý¼ Ý½ ¡¡¡ ÝÒµ eval Ü Ý ¾ ¼ Ò is continuous at
´Ú¼ Ú½ ¡¡¡ ÚÒµ, where ¾ÆÒ Ú ´ µ,
then Ó Just ´ ´Ú¼ Ú½ ¡¡¡ ÚÒµµ.
4.6 Applications of H-FRP
As an example of using H-FRP, this section discusses how we can expressive a commonly-
used form of controllers.
- kI
kP
R
u
kD d/dt
+ plant
e Y
In control systems, one important category of controllers is PID controllers, or Proportional-
Integral-Derivative controllers. The above diagram shows such a controller, where Ê is
the input to the system, and represents the desired output of the plant; is the actual
output of the plant; is the difference between and Ê: the error; the controller adds
up a signal proportional to , a signal proportional to the integral of , and a third signal
proportional to the derivative of , to obtain the control signal Ù. By adjusting the three
coefﬁcients È , Á, and , the stability and other characteristics of the controller can be
tuned.
106

With a small extension to H-FRP, a PID controller can be expressed as:
let behavior e lift ´ µ Ê
in lift ´ ´p i dµ È ¡p · Á ¡i · ¡dµ e íntegral eµ ´derivative eµ
where derivative is easily defined by a translation to RT-FRP as:
tr derivative let snapshot Ü tr in
let snapshot t time in
let snapshot ´x0 t0µ
delay ´¼ ¼µ éxt ´Ü tµµ
in ext íf t0 ¼ then ¼ else ´Ü x0µ ´t t0µµ
where Ü is a fresh variable.
Chapter summary
H-FRP is a subset of RT-FRP designed for hybrid real-time reactive systems. It has a
continuous-time based denotational semantics natural for modeling and reasoning about
hybrid systems, and a discrete operational semantics that can be executed on a digital
computer. We show that under suitable conditions, the operational semantics of an H-FRP
program converges to its denotational semantics. Most programs are expected to satisfy
these conditions. Compared with our previous work [53], the conditions we present in
this chapter are more accurate and are satisfied by a larger class of programs.
107

Chapter 5
Event-driven FRP
When a reactive system is programmed in RT-FRP, it is driven by a single stream of inputs.
The system advances in steps. At each step, the run-time engine samples (or polls) the en-
vironment to get the current input. Since in general there is no way to statically determine
which part of the system will be affected by the input, the whole system is traversed to
propagate this information, which is used to update the system state and generate the
response. Usually the system is run as fast as possible or at some ﬁxed pace deemed fast
enough.
Among all reactive systems, a large number are purely driven by multiple event sources:
such a system updates its internal state and changes its output only when an external
event occurs; between two event occurrences, the system does nothing. We call these
systems event-driven. One example of event-driven reactive systems is interrupt-driven
micro-controllers, which we encounter in building soccer-playing robots for the RoboCup
competition [46].
Traditionally, event-driven systems have been programmed using imperative languages
in a style known as event-handling: for each type of events, the user deﬁnes a call-back
function or procedure called the event handler (or the listener); when an event occurs, its
handler is invoked to update the system state and the output. Each event handler only
needs to change the part of the system state affected by that particular event. When no
108

event is occurring, the system does nothing.
In practice, this programming paradigm works well but has certain limitations (among
them scalability problems) that make it difficult for programming and maintaining large
scale systems (we will come back to these limitations later).
By using different input values to denote different events, we can program event-
driven systems in the RT-FRP framework. However, this is not always a good idea: in
RT-FRP the whole system is traversed at each step to propagate the input, even if only a
small part of the system is interested in the current event. For this reason, in applications
where performance is critical (such as micro-controllers), RT-FRP is often not suitable.
This chapter addresses this issue by defining a restricted form of RT-FRP called E-FRP
(for Event-Driven FRP), which does not have many of the problems the event-handling
approach suffers. In this language, an event impact analysis is used to determine which
part of the system is affected by which event. We also define a strategy for compiling
E-FRP to low-level code, and prove the correctness of the compilation. By incorporating
the result of the event impact analysis, the target code is made efficient.
We have found that E-FRP is well-suited for programming interrupt-driven micro-
controllers, which are normally programmed either in assembly language or some dialect
of C, and for writing controllers in a robot-simulation computer game named MindRover
[45], which is intended by its creator to be programmed in the object-oriented language
ICE [39].
In this chapter, we present the E-FRP language and its compilation, with an example
from our work on the RoboCup challenge.
5.1 Motivation
Before jumping into the details of the E-FRP language and how we compile it, it is impor-
tant to understand the nature of the problem we are trying to solve with E-FRP. This is the
goal of this section.
109

Our motivation for developing E-FRP comes from our work on building a team of
robots for the RoboCup soccer competition [46]. We found that programming the low-
level controllers on-board the robots in C is error-prone and tedious. Since the high-level
controllers are programmed in FRP, reasoning about the whole system is also a problem.
We tried to solve the problems by designing a language that is resource-bounded, efficient,
and natural for programming event-driven systems.
5.1.1 Physical model
First we describe the hardware profile of our robots.
The Yale RoboCup team consists of five radio-controlled robots, an overhead vision
system for tracking the two teams and a soccer ball, and a central FRP controller for guid-
ing the team. Everything is in one closed control loop.
Each robot is equipped with a radio receiver to get commands from the central con-
troller and a PIC16C66 micro-controller [33] to carry out the commands. PIC16C66 is a
primitive RISC processor that runs at a slow frequency and has only 4KB of RAM. Hence
the program has to be very efficient in CPU cycle and memory usage.
Each robot has two wheels mounted on a common axis and each wheel is driven by
an independent motor. For simplicity we focus on one wheel, and do not discuss the
interaction between the two.
The amount of power sent to the motor is controlled using a standard electrical engi-
neering technique called Pulse-Width Modulation (PWM): instead of varying the voltage,
the power is rapidly switched on and off (so the motor is in either the on or the off mode at
any time). The percentage of time when the power is on (called the duty cycle) determines
the overall power transmission.
Each wheel is monitored through a simple stripe detection mechanism: the more fre-
quently the stripes are observed by an infrared sensor, the faster the wheel is deemed to
be moving. For simplicity, we assume the wheel can only go in one direction.
110

5.1.2 The Simple RoboCup (SRC) controller
One of the tasks of the low-level controller running on PIC16C66 is to regulate the power
being sent to the motor, based on the speed sensor feedback and increase/decrease speed
instructions coming from the central FRP controller, so as to maintain a desired speed for
the wheel. We call this component the Simple RoboCup (SRC) controller, and describe it in
this section.
Figure 5.1 presents the block diagram of SRC, where we adopt the following conven-
tion:
¯ a dotted line carries an event;
¯ a solid line carries a behavior;
¯ a rectangle is a stateful behavior generator whose state can be updated by events;
¯ a shaded rectangle with round corners is a stateless behavior generator whose output
is a function of its input behaviors; behavior generators sometimes are also called
modules; and
¯ a small dark triangular mark at the end of a dotted line means the event affects this
stateful module “later.” This annotation is useful when one event affects more than
one module and we need to specify the order in which they are updated. In this
example, both speed and duty cycle react to the event ClkSlow, but when ClkSlow
occurs, duty cycle is updated ﬁrst.
There are ﬁve behaviors in this control system:
¯ desired speed and speed are the desired speed and the measured speed of the
wheel, respectively;
¯ duty cycle is a number between 0 and 100 determining what percentage of time the
motor should be on;
111

duty cycledesired speed
speed count
power M
IncSpd DecSpd ClkSlow ClkFastStripe
SRC
Motor Wheel
with stripes
IR sensor
Figure 5.1: Simple RoboCup Controller: block diagram
¯ count is a counter that repeatedly goes from 0 to 100; and
¯ power is a Boolean behavior which determines the motor’s on/off status.
These behaviors are driven by ﬁve independent event sources:
¯ IncSpd and DecSpd increment and decrement the desired speed;
¯ Stripe occurs 32 times for every full revolution of the wheel;
¯ ClkFast and ClkSlow are two clocks that tick at regular, but different, intervals. The
frequency of ClkFast is much higher than that of ClkSlow.
When the IR sensor detects a stripe passing under it, it generates a Stripe event, which
triggers the speed behavior to increment. With each ClkSlow occurrence, speed is reset
to 0. Since ClkSlow occurs at regular intervals, speed counts the number of Stripe’s in a
ﬁxed period of time, which corresponds to the actual wheel speed. When ClkSlow occurs,
before speed is reset, its value is compared with desired speed to determine duty cycle.
The triangular “delay” mark makes sure duty cycle is updated before speed. The behavior
112

count increments each time ClkFast occurs, and resets to 0 after reaching 100. Finally,
power is determined by comparing duty cycle and count, and is updated when either of
its inputs is updated.
5.1.3 Programming SRC with event handlers
Initially, this low-level controller was programmed in a specialized subset of C, for which
a commercial compiler targeting PIC16C66 exists. The essence of the code can be found
in Figure 5.2, where s, ds, and dc are used for speed, desired speed, and duty cycle
respectively.
void init() {
ds = s = dc = count = power = 0;
}
void on_IncSpd() {
ds++;
}
void on_DecSpd() {
ds--;
}
void on_Stripe() {
s++;
}
void on_ClkSlow() {
dc = dc < 100 && s < dc ? dc + 1
: dc > 0 && s > ds ? dc - 1
: dc;
power = count < dc;
s = 0;
}
void on_ClkFast() {
count = count >= 100 ? 0 : count + 1;
power = count < dc;
}
Figure 5.2: The SRC controller in C
113

Even this fairly small example reveals some problems with the event-handling ap-
proach for programming event-driven systems:
1. The modularity needs improvement.
If you try to find the definition for the speed module in Figure 5.2, where it is called
s, you will notice that the definition is scattered among three functions: init(),
on_Stripe(), and on_ClkSlow(). This is against the software engineering prin-
ciple of providing logically indivisible information in one single place.
In general, to implement a behavior that is affected by Ò events, the programmer
needs to insert code to all of the Ò event handlers. Consequently, to understand ,
the reader has to walk through the whole program to find every place is updated,
which is tedious and error-prone. Worse yet, if the programmer decides to drop in
some new modules to the system (for example, the same controller is duplicated to
drive another wheel), he will have to patch existing event handlers with new pieces
of code1. The program loses its modularity here.
Control engineers model event-driven systems using block diagrams, and we should
therefore make the transition from these diagrams to programs as smooth as possi-
ble. The event-handling approach leaves a lot to be desired here.
2. Code is sometimes duplicated.
We notice that the line “power = count < dc;” appears in both on_ClkSlow()
and on_ClkFast(). In general, if the inputs of a stateless behavior are affected
by Ò events, then the code for updating will be repeated Ò times in all those event
handlers. When the definition of needs to be changed, the programmer has to
propagate the change to all of the Ò event handlers. The amount of effort grows
1
In the Java event model, more than one listener can subscribe to an event. Hence a Java programmer can
extend an event listener (or a group of them) without modifying existing code by registering a new listener
with the same event. However, this is not satisfactory either, since to understand the system, the reader
now needs to study both the definitions of multiple event listeners and the order they are registered. As the
definition of a listener and the registration of it are in different parts of the program, the modularity is broken.
114

with the size of the system. It will not surprise us if some event handlers are missed
or other mistakes are made in this process.
In an ideal programming language, the user only needs to specify the relation be-
tween the input and the output of a stateless behavior generator once, and should
be able to change the deﬁnition later by making easy local changes, which is partic-
ularly beneﬁcial for large-scale systems.
3. The order of assignments can be confusing.
In each event handler, a series of assignments are executed to update a group of
behaviors. While sometimes the order of these assignments is essential, sometimes
it is irrelevant. For example, we cannot change the function on_ClkSlow() to
void on_ClkSlow() {
power = count < dc;
dc = dc < 100 && s < dc ? dc + 1
: dc > 0 && s > ds ? dc - 1
: dc;
s = 0;
}
while it is OK to write it as
void on_ClkSlow() {
dc = dc < 100 && s < dc ? dc + 1
: dc > 0 && s > ds ? dc - 1
: dc;
s = 0;
power = count < dc;
}
115

Although the effect of assignment order is clear for small systems like SRC, it can be
rather confusing for a system that involves hundreds of behaviors. In fact, what is
important is what the behaviors are updated to, not how. The burden for specifying
the order of assignments is just an artifact of the imperative programming paradigm,
and we would like to be able to avoid this over-specification.
4. While C can generate very efficient target code, it is a poor language to write resource-
bounded programs in (any experienced C programmer knows how difficult it is to
fight those dangling pointers and leaked memory). For a system with fairly limited
processing power and hard requirement on response time, the ability to guarantee
resource bounds is very important.
5. Finally, it is difficult to reason about the combination of the main FRP controller and
these separate controllers in C. This problem would not exist if the controllers are
all written in FRP, or a subset thereof.
5.2 The E-FRP language
E-FRP is our attempt to solve the problem of programming event-driven real-time reac-
tive systems naturally, efficiently, and reliably. It has a simple operational semantics from
which it is immediate that the program is resource bounded. The compiler generates re-
source bounded, but bloated, target code. However, we are able to substantially enhance
the target code by a four-stage optimization process.
Before presenting the details, some basic features of the E-FRP execution model need
to be explained.
5.2.1 Execution model
As with RT-FRP, the two most important concepts in E-FRP are events and behaviors.
Events are time-ordered sequences of discrete event occurrences. Behaviors are values
116

that react to events, and can be viewed as time-indexed signals. Unlike RT-FRP behaviors
that can change whenever the system is sampled, E-FRP behaviors can change value only
when an event occurs.
In RT-FRP, events are just behaviors of Maybe « types, and can be defined in the nor-
mal way a behavior is defined. In E-FRP, the user declares a finite set of events that will
be used in the program, and cannot create new events at run-time. On different target
platforms, events may have different incarnations, like OS messages, or interrupts (as in
the case of micro-controllers). E-FRP events are mutually exclusive, meaning that no two
events ever occur simultaneously. Such are the same assumptions used by the event-
handling approach. These design decisions avoid potentially complex interactions be-
tween event handlers, and thus greatly simplifies the semantics and the compiler. For
simplicity, E-FRP events do not carry values with their occurrences, though there is no
technical difficulty in making them do so.
There are two kinds of behaviors: stateless and stateful. A stateless behavior can be
viewed as a pure function whose inputs are other behaviors, or it can be a constant when
there is no input. The value of depends solely on its current input, and is not affected
by the history of the input at all. In this sense, is like a combinatorial circuit. A stateful
behavior sf has a state that can be updated by event occurrences. The value of sf depends
on both the current input and its state. Therefore sf is analogous to a sequential circuit.
A program defines a collection of behaviors. On the occurrence of an event, execution
of an E-FRP program proceeds in two distinct phases: The first phase involves carrying out
computations that depend on the previous state of the computation, and the second phase
involves updating the state of the computation. To allow maximum expressiveness, E-
FRP allows the programmer to insert annotations to indicate in which of these two phases
a particular change in behavior should take place.
117

³ À sf È
Phases ¨ ¿³
¬
¬ later
Event handlers À Á µ ³
Stateful behaviors sf init Ü Ú in À
Behaviors
¬
¬ sf
Programs È Ü
Î ´sfµ
Î ínit Ü Ú in Á µ ³ µ
Ë
Î ´ µ Ü
Figure 5.3: Syntax of E-FRP and definition of free variables
5.2.2 Syntax
Figure 5.3 defines the syntax of E-FRP and the notion of free variables. The syntactic cat-
egory Á is for event names drawn from a finite set Á. The category stands for the empty
term. An event Á cannot occur more than once in an event handler À, and a variable Ü
cannot be defined more than once in a program È.
The terms and Ú are expressions and values of the base language respectively. As we
are using BL as the base language in this thesis, they have been defined in Section 2.1. The
only thing to note is that is also called a “stateless behavior” in E-FRP, while it is called
an expression in BL.
A stateful behavior sf init Ü Ú in Á µ ³ initially has value Ú, and changes to
the current value of when event Á occurs. Note that Ü is bound to the old value of sf and
can occur free in . As mentioned earlier, the execution of an E-FRP program happens
in two phases. Depending on whether ³ is or later, the change of value takes place in
either the first or the second phase, respectively.
A program È is just a set of mutually recursive behavior definitions.
Î ´ µ denotes the free variables in behavior . As can be either or sf, and Î ´ µ
has been defined in Section 2.2.2, we only need to define Î ´sfµ here.
118

5.2.3 Type system
The type system of E-FRP is simple and established on the basis of the type system of the
base language.
Typing judgments
To avoid clutter, we choose to reuse the same typing judgment notation we used for the
base language. In other words, while we write « for “ is an expression of type «
in context ,” we will write
«
for “ is a behavior of type « in context .”
Since the category is defined as
¬
¬ sf
the definition of « can be presented in two parts, namely « and sf «.
The definition of the former is the same as in Section 2.2, which justifies the overloading
of the notation. Depending on the context, « can be read either “ is an expression
of type «” or “ is a stateless behavior of type «.”
The meaning of sf « is defined in Figure 5.4. The same figure also defines
È
which can be read “context assigns types to behaviors in È.”
Acyclicity requirement
We must point out that an important requirement for valid E-FRP programs is not cap-
tured by the type system: namely, we do not allow the behavior definitions to be cyclic.2
2
What it exactly means to be cyclic will become clear in Section 5.4.1.
119

sf «
Ú « ¨ Ü « «
init Ü Ú in Á µ ³ «
È
Ü « «
Ü
Figure 5.4: Type system of E-FRP
Instead, this check is performed by the compilation process. As we will see in Section
5.4.1, if a program contains cyclic definitions, the compilation will fail. A program is valid
only when both it is type-correct and the compilation for it succeeds.
Although we could have encoded the acyclicity requirement using a more advanced
type system, the resulting type system would inevitably be complicated and difficult to
understand. Besides, it would be redundant since this constraint is already enforced by
the compilation process.
5.2.4 Operational semantics
We now give an operational semantics to E-FRP.
Environments
We will continue to use the concept of environment defined in Section 2.3. An environment
maps variables to values, and we repeat its syntax here:
Ü Ú
Execution judgments
Figure 5.5 defines the operational semantics of an E-FRP program by means of four judg-
ments. The judgments can be read as follows:
120

¯ È
Á
¶ Ú: “on event Á, behavior yields Ú;”
¯ È
Á
· ¼: “on event Á, behavior is updated to ¼;”
¯ È Á
Ú ¼: “on event Á, behavior yields Ú, and is updated to ¼;” This is merely
shorthand for È Á
¶ Ú and È Á
· ¼; and
¯ È Á
È¼: “on event Á, program È yields environment and is updated to È ¼.”
In the definition of these judgments, we will need to use the judgment ¸ Ú defined
in Section 2.3.
È Á
¶ Ú
Î ´ µ Ü ¾Ã È È¼ Ü ¾Ã
Ò
È
Á
¶ Ú
Ó ¾Ã
Ü Ú ¾Ã ¸ Ú
È Á
¶ Ú
é1µ
È Ü Ú Á
¶ Ú¼
È init Ü Ú in Á µ À
Á
¶ Ú¼
é2µ
À Á µ À¼
È init Ü Ú in À Á
¶ Ú
é3µ
È Á
· ¼
È
Á
·
ú1µ
À Á µ ³ À¼ È Ü Ú
Á
¶ Ú¼
· init Ü Ú¼ in À
ú2µ
À Á µ ³ À¼
· init Ü Ú in À
ú3µ
È
Á
È¼
Ò
Ü ¾Ã Á
Ú ¼
Ó ¾Ã
Ü ¾Ã Á
Ü Ú ¾Ã Ü ¼ ¾Ã
´pµ
Figure 5.5: Operational semantics of E-FRP
121

When an event Á occurs, if a behavior sf reacts to Á immediately, then we update sf
immediately; if sf reacts to Á later, then we do not update sf until all behaviors that depend
on sf have been updated.
Assuming the base language is deterministic, we can show that the whole E-FRP lan-
guage is deterministic:
Lemma 5.1 (Deterministic semantics). If the base language is deterministic, then we
have that
´È Á
È and È Á ¼ È¼µ µ ´
¼ and È È¼µ
The complete proof for this lemma can be found in Appendix A.3. In short, the proof
is in two parts, with the first being an induction on the derivation of È Á
¶ Ú, and the
second being an induction on the derivation of È Á
· ¼.
5.2.5 SRC in E-FRP
Figure 5.6 presents in E-FRP the SRC controller we introduced in Section 5.1.2. In what
follows we explain the definition of each of ds, s, dc, count, and power in detail.
The desired speed ds is defined as an “init-in” construct, which can be viewed as a
state machine that changes state whenever an event occurs. The value of ds is initially
0, then it is incremented (or decremented) when IncSpd (or DecSpd) occurs. The local
variable x is used to capture the value of ds just before the event occurs.
The current speed measurement s is initially 0, and is incremented whenever a stripe
is detected (the Stripe interrupt). This value, however, is only “inspected” when ClkSlow
occurs, at which point it is reset to zero. The Ð Ø Ö annotation means that this resetting is
not carried out until all other first-phase activities triggered by ClkSlow have been carried
out (that is, it is done in the second phase of execution).
The duty cycle dc directly determines the amount of power that will be sent to the
motor. On ClkSlow, the current speed s is compared with the desired speed ds (Recall
that s is reset by ClkSlow in the second phase, after all the first-phase computations that
122

depend on the penultimate value of s have been completed). If the wheel is too slow
(or too fast) then the duty cycle is incremented (or decremented). Additional conditions
ensure that this value remains between 0 and 99.
The current position in the duty cycle is maintained by the value count. This value is
incremented every time ClkFast occurs, and is reset every 100 ClkFast interrupts. Hence
it counts from 0 to 99 repeatedly. The actual False/True signal going to the motor is
determined by the value of power. Since power is True only when count dc, the larger
dc is, the more power is sent to the motor, and hence the more speed. Note that power is
updated whenever count or dc changes value.
ds init x ¼ in IncSpd µx · ½
DecSpd µx ½
s init x ¼ in ClkSlow µ¼ later,
Stripe µx · ½
dc init x ¼ in ClkSlow µif x ½¼¼ s ds
then x · ½
else if x ¼ s ds
then x ½
else x
count init x ¼ in ClkFast µif x ½¼¼ then ¼
else x · ½
power count dc
Figure 5.6: The SRC controller in E-FRP
Inspecting this example, we can show that E-FRP solves or makes improvements in
each of the problems we mentioned for the event-handling approach in Section 5.1.3:
1. The modularity is improved.
In the event-handling style, the programmer deﬁnes the impact of the events one
by one. E-FRP adopts a behavior-oriented view, where the programmer deﬁnes
behaviors one by one. Our experience is that in practice it is much more likely for a
123

user to change, add, or remove behaviors than to do the same with events.
However, we understand that there are situations where the event-oriented view is
preferred (e.g. when one is interested in the effect on the state induced by a partic-
ular event), and we do not claim that the behavior-oriented view is always supe-
rior (although it is usually the case). Fortunately, our compiler generates the event-
oriented view from the behavior-oriented view, so the user can always look at the
target code when the event-oriented view is needed.
2. Code duplication for stateless behaviors is eliminated.
In E-FRP, we only need to define a stateless behavior once, no matter it is affected
by how many events.
3. There is no more confusing order of assignments.
An E-FRP program only specifies the relations between the behaviors and the events.
It is not concerned with the exact order in which the behaviors are updated, and re-
lies on the compiler to figure it out. The only exception is when one behavior wants
to have access to the value of another behavior before it updates, in which case the
programmer inserts a later annotation.
In fact, the order of behavior definitions and event-handler branches in no way af-
fects the semantics of an E-FRP program. Hence the reader is relieved from trying
to understand why a particular order is used.
4. The program is guaranteed to be resource-bounded, as we will show later.
5. We are also going to show that E-FRP has an operational semantics in the same
style of that of RT-FRP. Thus reasoning about mixed systems programmed in both
languages is feasible.
124

5.3 SimpleC: an imperative language
The PIC16C66 does not need to be programmed in assembly language, as there is a com-
mercial compiler that takes as input a restricted C. We compile E-FRP to a simple imper-
ative language we call SimpleC, from which C or almost any other imperative language
code can be trivially generated.
5.3.1 Syntax
The syntax of SimpleC is defined in Figure 5.7. Again, is the base language expression.
Assignment sequences Ü
Programs É ´Á ¼ µ
Figure 5.7: Syntax of SimpleC
A program É is just a collection of event handler function definitions. An event han-
dler has the form ´Á ¼µ, where Á is the event to be handled and also serves as the
name of the function. The function body is split into two consecutive parts and ¼,
which are called the first phase and the second phase respectively. The idea is that the pro-
gram É executes in an environment that defines all free variables in É, and when an event
Á occurs, first is executed to update the environment to match that yielded by the source
program, then ¼ is executed to prepare the environment for the next event.
Note that we reuse the base language expression here for SimpleC computations.
We do this because we are not interested in compiling the base language to a low-level
language. In particular, BL is resource-bounded and first-order, and it is not difficult to
devise a way for encoding BL expressions and values in C. As we will show later, for our
approach of compiling E-FRP to SimpleC to work, we shall require that the values in the
base language contain no free variables. In other words, we require that Î ´Úµ for all
value Ú. By Lemma 2.6 in Section 2.4, BL holds this property.
125

5.3.2 Compatible environments
SimpleC programs are environment transformers: given an initial environment which
defines every variable in the program, when an event occurs, the corresponding event
handler is executed, which changes the values of the variables in the environment.
Obviously, a SimpleC program É cannot work with an arbitrary environment —
the value assigns to a variable Ü must have a type compatible with the usage of Ü in É.
Hence we define the concepts
¯ “assignments is compatible with context ” (written ),
¯ “environment and assignments are compatible under context ” (written
), and
¯ “environment and program É are compatible under context ” (written É)
as

´Ü µ
Ü

É

Ò

¼
Ó
´Á ¼ µ
where the judgment has been defined in Section 2.3.
5.3.3 Operational semantics
Figure 5.8 gives an operational semantics to SimpleC, where the judgments are read as
follows:
¯ ¸ ¼: “executing assignment sequence updates environment to ¼.”
126

¸ ¼
¸
ć1µ
Ü Ú ¸ Ú¼
Ü Ú¼ ¸ ¼
Ü ·· Ü Ú ¸ ¼ ć2µ
É
Á
¸ ¼ ¼¼
Á ¾ Á
´Á ¼ µ
Á
¸
ć3µ
¸ ¼ ¼ ¼ ¸ ¼¼
´Á ¼µ É
Á
¸ ¼ ¼¼
ć4µ
Figure 5.8: Operational semantics of SimpleC
¯ É
Á
¸ ¼ ¼¼: “when event Á occurs, program É updates environment to ¼
in the first phase, then to ¼¼ in the second phase.”
The rules are straightforward and do not need explanation. Basically SimpleC has the
standard semantics of an imperative language that has no control structure except se-
quential assignment statements.
5.3.4 Properties
Definition 5.1. Similar to the corresponding concepts for the base language defined in
Section 2.4, we say that:
¯ SimpleC is productive, if µ ¼ ¸ ¼,
¯ SimpleC is deterministic, if ¸ ¼ ¸ ¼¼ µ ¼ ¼¼,
¯ SimpleC is type-preserving, if ´ and ¸ ¼µ µ
¼, and
¯ SimpleC is resource-bounded, if ´ and ¸ ¼µ µ the size of the
derivation tree of ¸ ¼ is bounded.
It is easy to show that SimpleC is productive, deterministic, type-preserving, and
resource-bounded, given that the base language holds the same properties:
127

Lemma 5.2 (Productivity). If the base language is productive and type-preserving, then
SimpleC is productive.
Proof. By induction on .
1. . By rule c1, we have ¸ and are done.
2. Ü ·· ½. Since , we know that ´Üµ. Since
and the base language is terminating, we know that there are Ú, Ú¼, and ½ such that
Ü Ú ½ and ¸ Ú¼. Furthermore, since the base language is type-
preserving, we also know that Ú¼ ´Üµ. Therefore Ü Ú¼ ½ ½. By
induction hypothesis, there is ¼ such that ½ Ü Ú¼ ½ ¸ ¼. According to
rule c2, we have that ¸ ¼ and are done.
Lemma 5.3 (Determinism). If the base language is deterministic, then SimpleC is deter-
ministic.
Proof. Let ½ be the derivation tree for ¸ ½, and ¾ be that for ¸ ¾. The
proof is by induction on ½.
1. The last rule used in ½ is c1. In this case, , and we have ½ ¾.
2. The last rule in ½ is c2. There are Ü Ú ½ Ú¼, and ½ such that
(a) Ü Ú ½,
(b) Ü ··
¼,
(c) ¸ Ú¼, and
(d) ½ Ü Ú¼
½ ¸ ¼.
In this case, the last rule in ¾ must be c2 too, and there must be Ú¼¼ such that
(a) ¸ Ú¼¼, and
128

(b) ½ Ü Ú¼¼ ½ ¸ ¼¼.
However, since the base language is deterministic, we know that Ú¼ Ú¼¼. By induc-
tion hypothesis, this leads to that ¼ ¼¼. And we are done.
Lemma 5.4 (Type preservation). If the base language is type-preserving, then SimpleC is
type-preserving.
Proof. By induction on the derivation of ¸ ¼:
1. The last rule used is c1. We have that and ¼. It follows trivially that

¼.
2. The last rule is c2. We have that there are ½ ½ Ü Ú Ú¼ such that
(a) Ü Ú ½,
(b) Ü ·· ½,
(c) ¸ Ú¼, and
(d) ½ Ü Ú¼
½ ¸ ¼.
Since , we have that ´Üµ. Since , ¸ Ú¼, and the base
language is type-preserving, we have Ú¼ ´Üµ, and therefore Ü Ú¼ ½.
Hence Ü Ú¼ ½ ½.
Since ½ Ü Ú¼
½ ¸ ¼, by induction hypothesis, we have that
¼.
Lemma 5.5 (Resource bound). If the base language is resource-bounded, then SimpleC
is resource-bounded.
Proof. Given and ¸ ¼, let Ò be the length of , and be the derivation
of ¸ ¼. We note that in , we use the rule c1 once and c2 Ò times. Each time c2
129

is used, we derive ¼¼ Ú for some ¼¼, , and Ú. Since we assume the base language
is resource-bounded, the size of the derivation of ¼¼ Ú is bounded. As there are Ò
such derivations in , the size of is also bounded.
5.4 Compilation from E-FRP to SimpleC
One of our main contributions is a provably correct compiler from E-FRP to SimpleC. This
section presents such a compiler implemented in Haskell, and proves that it is correct.
5.4.1 Compilation strategy
A compilation strategy is described by a set of judgments presented in Figure 5.9. The
judgments are read as follows:
¯ Ü : “ does not depend on Ü or any variable updated in .“
¯ È ½
Á : “ is the first phase of È’s event handler for Á.”
¯ È ¾
Á : “ is the second phase of È’s event handler for Á.”
¯ È É: “È compiles to É.”
In the object program, besides allocating one variable for each behavior defined in the
source program, we allocate a temporary variable Ü· for each stateful behavior named Ü.
Temporary variables are necessary for compiling certain recursive definitions.
Implicit in this compilation process is an event impact analysis that determines which
behaviors are affected by a given event Á. In the event handler for Á, we only need to
update those behaviors affected by Á.
The compilation relation is clearly decidable, but the reader should note that given a
program È, È É does not uniquely determine É. Hence, this is not a just specifica-
tion of our compiler (which is deterministic), but rather, it allows many more compilers
than the one we have implemented. However, we will show in Section 5.4.3 that any É
satisfying È É will behave in the same way.
130

Note also that if there is cyclic data dependency in an E-FRP program È, we will not
be able to find a É such that È É. The restriction that the set of possible events is
known at compile time and the events are mutually exclusive (i.e. no two events can be
active at the same time) allows us to perform this check.
Since the target code only uses fixed number of variables, has finite number of assign-
ments, has no loops, and does not dynamically allocate space, it is obvious that the target
code can be executed in bounded space and time.
5.4.2 Compilation examples
The workings of the compilation relation are best illustrated by some examples. Consider
the following source program:
x1 init x ¼ in Á½ µx · x2
x2 init y ½ in Á¾ µy · x1
Here x1 depends on x2, and x2 depends on x1, but they only depend on each other in
different events. Within each event, there is no cyclic dependency. Hence this program
can be compiled to the following SimpleC program:
´Á½ x1 x1·
· x2 x1·
x1 µ
´Á¾ x2 x2·
· x1 x2·
x2 µ
Consider the following source program:
x1 init x ¼ in Á µx · x2
x2 init y ½ in Á µx1 later
Here x1 and x2 are mutually dependent in Á, but their values are updated in different
phases. In each phase, the dependency graph is acyclic. Hence this program compiles
131

Ü
Î ´ µ ´ Ü Ü µ
Ü Ü
È ½
Á
½
Á
´x1µ
È ½
Á Ü
Ü È ½
Á Ü ··
´x2µ
È ½
Á Ü Ý Ü·
Ü init Ý Ú in Á µ À È ½
Á Ü Ý Ü· ··
´x3µ
È ½
Á Ü· Ý Ü
Ü init Ý Ú in Á µ later À È ½
Á Ü· Ý Ü ··
´x4µ
È ½
Á À Á µ ³ À¼
Ü init Ý Ú in À È ½
Á
´x5µ
È ¾
Á
¾
Á
´x6µ
È ¾
Á Ü
Ü È ¾
Á Ü ··
´x7µ
È ¾
Á
Ü init Ý Ú in Á µ À È ¾
Á Ü· Ü ··
´x8µ
È ¾
Á
Ü init Ý Ú in Á µ later À È ¾
Á Ü Ü· ··
´x9µ
È ¾
Á À Á µ ³ À¼
Ü init Ý Ú in À È ¾
Á
´x10µ
È É
È ½
Á Á È ¾
Á
¼
Á
Á¾Á Ë
Î ´ µ Ü where Ü È
È ´Á Á
¼
Áµ
Á¾Á
Figure 5.9: Compilation of E-FRP
132

too, and one acceptable compilation for it is:
´Á x1 x1·
· x2 x2·
x1 x1·
x1 x2 x2·
µ
However, if the deﬁnition for x2 were
x2 init y ½ in Á µx1
then the code would have been rejected.
If we let both x1 and x2 be updated in the later phase, i.e. let the program È be
x1 init x ¼ in Á µx · x2 later
x2 init y ½ in Á µx1 later
then one possible translation of È in SimpleC is
´Á x1·
x1 · x2 x2·
x1 x1 x1·
x2 x2·
Finally, we present in Figure 5.10 the target code we got from compiling the SRC con-
troller.
5.4.3 Correctness of compilation
When an event Á occurs, a behavior Ü in an E-FRP program can be updated to have a new
value Ú. To prove that our compiler is correct, we need to show that after executing the
event handler for Á, the corresponding variable(s) of Ü in the target program will have the
same value Ú. The following concept is useful for formalizing this intuition:
Deﬁnition 5.2 (Program state). The state of a program È, written as ×Ø Ø ´Èµ, is an envi-
133

ÍncSpd ds ds·
· ½ power count dc
ds·
ds power count dc µ
´DecSpd, ds ds·
½ power count dc
ds·
ds power count dc µ
´Stripe s s· · ½ power count dc
s· s power count dc µ
ĆlkSlow s· ¼ dc if dc·
½¼¼ s ds then dc·
· ½
else if dc·
¼ s ds then dc·
½
else dc·
power count dc
s s· dc·
dc power count dc µ
ĆlkFast count if count· ½¼¼ then ¼ else count· · ½
power count dc
count· count power count dc µ
Figure 5.10: The SRC controller in SimpleC
ronment defined by:
×Ø Ø ´Èµ Ü ×Ø Ø È ´ µ
¾Â Ý ×Ø Ø È ´sf µ Ý·
×Ø Ø È ´sf µ
¾Ã
where
¯ È Ü ¾Â Ý sf ¾Ã,
¯ ×Ø Ø È ´ µ Ú where È
Query
¶ Ú, and
¯ Query ¾Áis a special event whose sole purpose is to reveal the state of the program
without updating it; the user cannot use Query in the program.
It is obvious that ×Ø Ø ´ µ possesses the following properties:
Lemma 5.6. If È and È É, then ×Ø Ø ´Èµ is uniquely defined.
Lemma 5.7. Given È Ü ¾Â Ý sf ¾Ã, if È and È É, then
Ò
Ý·
´Ý µ
Ó ¾Ã
×Ø Ø ´Èµ É.
134

The following lemma shows that if a program È can be compiled, then it can be exe-
cuted at the source level. This means the compiler does not accept invalid code.
Lemma 5.8. If È and È É, then there are and È ¼ such that È Á
È¼.
Furthermore, if È compiles to É, then É is a valid program that can be executed suc-
cessfully under environment ×Ø Ø ´Èµ:
Lemma 5.9. If È and È É, then there are ½ and ¾ such that É ×Ø Ø ´Èµ
Á
¸
½ ¾.
Finally, we show that the compilation is correct in the sense that updating an E-FRP
program does not change its translation in SimpleC, and that the source program gener-
ates the same result as the target program:
Theorem 5.1 (Source-target correspondence). Given that È, È É, and È Á
È¼,
we have
1. È¼ É; and
2. if É ×Ø Ø ´Èµ
Á
¸ ¼ ¼¼, then ¼ and ¼¼ ×Ø Ø ´È¼µ.
The second part of the theorem can be illustrated by the ﬁgure below:
È
¯¯
×Ø Ø
¯¯
Á È¼
¯¯
×Ø Ø
¯¯
É ¼
Á
¸
¼ ¼¼
The proof of this theorem is rather lengthy and therefore omitted here. Interested
readers can ﬁnd it in Section A.3 of the Appendix. The core of the proof is an induction
on the derivation of the compilation process.
Writing
È
Á½
½ È½
Á¾
¡¡¡ ÁÒ
Ò ÈÒ
135

as shorthand for È
Á½
½ È½, È½
Á¾
¾ È¾, . . . , and ÈÒ ½
ÁÒ
Ò ÈÒ, and
É ¼
Á½
¸ ¼
½
¼¼
½
Á¾
¸ ¡¡¡ ÁÒ
¸ ¼
Ò
¼¼
Ò
for É ¼
Á½
¸ ¼
½
¼¼
½ , É ½
Á¾
¸ ¼
¾
¼¼
¾ , and É Ò ½
ÁÒ
¸ ¼
Ò
¼¼
Ò , we show that for any
input event sequence, the result of the object code step-wise matches that of the source
code:
Corollary 5.1 (Compilation correctness). Given that È, È É, È
Á½
½ È½
Á¾
¡¡¡ ÁÒ
Ò ÈÒ, and É ¼
Á½
¸ ¼
½
¼¼
½
Á¾
¸ ¡¡¡ ÁÒ
¸ ¼
Ò
¼¼
Ò , we have that for all ¾ ÆÒ, ¼ and
¼¼ ×Ø Ø ´È µ.
The corollary can be illustrated by the ﬁgure below:
È
¯¯
×Ø Ø
¯¯
Á½ ½ È½
¯¯
×Ø Ø
¯¯
Á¾ ¡¡¡ ÁÒ Ò ÈÒ
¯¯
×Ø Ø
¯¯
É ¼
Á½
¸
¼
½
¼¼
½
Á¾
¸ ¡¡¡ ÁÒ
¸
¼
Ò
¼¼
Ò
Proof. The proof is by repeatedly applying part 2 of Theorem 5.1.
5.4.4 Optimization
The compiler that we have described, although provably correct, generates only na¨ıve
code that leaves a lot of room for optimization. Besides applying known techniques for
optimizing sequential imperative programs, we can improve the target code by taking
advantage of our knowledge of the compiler. In particular, we implemented a compiler
that does:
1. Ineffective code elimination: Given a deﬁnition Ü in the source program, Ü is
affected by a particular event Á only when one of the following is true:
(a) is a stateful behavior that reacts to Á; or
136

È É µ½ É¼ ´Ü µ ¾È Î ´ µ ÄÎ ´ µ
È É ´Á ·· Ü ··
¼ ¼¼µ µ½ É ´Á ··
¼ ¼¼µ
´Ü µ ¾È Î ´ µ ÄÎ ´
¼µ
È É ´Á ¼ ·· Ü ··
¼¼µ µ½ É ´Á ¼ ··
¼¼µ
È É µ¾ É¼ Ü· ¾ Î ´ µ
È É ´Á ·· Ü ··
¼ ¼¼µ µ¾
É ´Á ·· Ü Ü· Ü ··
¼ ¼¼µ
È É µ¿ É¼ Î ´ µ ÄÎ ´ ¾µ
È É ´Á ½ ·· Ü· ·· ¾ ¿ ·· Ü Ü· ·· µ
µ¿ É ´Á ½ ·· ¾ ·· Ü Ü· Ü ·· ¿ ·· µ
È É µ É¼ É É¼ ´Á ·· Ü· ··
¼ ¼¼µ Ü· ¾ÊÎ ´Éµ
È É µ É¼ ´Á ··
¼ ¼¼µ
É É¼ ´Á ¼ ·· Ü· ··
¼¼µ Ü· ¾ÊÎ ´Éµ
È É µ É¼ ´Á ¼ ··
¼¼µ
È É µ£ É¼
È É µ£ É
È É µ£ É¼ È É¼ µ É¼¼
È É µ£ É¼¼
È É µ É¼ È É µ£ É¼ É¼¼ È É¼ µ É¼¼
È É µ É¼
È É µ É¼
È É È É µ½ É½ È É½ µ¾ É¾
È É¾ µ¿ É¿ È É¿ µ É¼
È É µ É¼
Figure 5.11: Optimization of the target code
137

(b) is a stateless behavior, and one of the variables in Î ´ µ is affected by Á.
It is obvious that whether Ü is affected by Á can be determined statically. If Ü is not
affected by Á, the code for updating Ü in the event handler for Á can be eliminated.
This optimization helps reduce the code size as well as the response time.
2. Temporary variable elimination: The value of a temporary variable Ü· cannot be
observed by the user of the system. Hence there is no need to keep Ü· around
if it can be eliminated by some program transformations. This technique reduces
memory usage and the response time.
We deﬁne the right-hand-side variables (written ÊÎ ) of a collection of assignments, and
the left-hand-side variables (written ÄÎ ) of a collection of assignments, as
ÊÎ ´ µ ÊÎ ´ Ü µ
Ë
Î ´ µ
ÊÎ ´Éµ ÊÎ ´ ´Á ¼ µ µ
Ë
ÊÎ ´ µ ÊÎ ´
¼ µ
ÄÎ ´ µ ÄÎ ´ Ü µ Ü
The optimizations are carried out in four stages, where each stage consists of a se-
quence of one particular kind of transformations. In each stage, we keep applying the
same transformation to the target code till it cannot be applied any further.
The purpose of stage 1 is to eliminate unnecessary updates to variables. One such
update is eliminated in each step.
The code produced by the unoptimizing compiler has the property that at the begin-
ning of phase 1 of any event handler, Ü and Ü· always hold the same value. Stage 1
optimization preserves this property. Hence in stage 2, we can safely replace the occur-
rences of Ü· on the right hand side of an assignment in phase 1 with Ü. This reduces the
usage of Ü· and thus helps stage 4.
Since stage 1 and stage 2 are simple, we can easily write a compiler that directly gen-
erates code for stage 3. However the proof of the correctness of this partially-optimizing
138

compiler then becomes complicated. Therefore we choose to present stage 1 and stage 2
as separate optimization processes.
We call the transformation in stage 3 “castling” for its resemblance to the castling spe-
cial move in chess: if an event handler updates Ü· in phase 1 and assigns Ü· to Ü in phase
2, under certain conditions we can instead update Ü at the end of phase 1 and assign Ü to
Ü· at the beginning of phase 2. This transformation reduces right-hand-side occurrences
of Ü·, thus making it easier to be eliminated in stage 4. Note that the correctness of this
transformation is non-trivial.
If the value of a temporary variable Ü· is never used, then there is no need to keep Ü·
around. This is what we do in stage 4.
Figure 5.11 formally defines the optimization. Given a source program È, we write
È É µ É¼ for “É is transformed to É¼ in one step in stage ,” where ½ ; we
write È É µ£ É¼ for “É is transformed to É¼ in zero or more steps in stage ;” and
we write È É µ É¼ for “É¼ is the furthest you can get from É by applying stage
transformations.” Finally, we write È É µ É¼ for “È compiles to É, which is then
optimized to É¼.”
As an example, Figure 5.12 presents the intermediate and final results of optimizing
the SRC program. Stage 1 optimization generates É½, where all unnecessary updates
to power have been eliminated. Then stage 2 gets rid of all right-hand-side temporary
variables in phase 1, as in the change from ds ds·
· ½ to ds ds · ½, and the result
is É¾. In stage 3 we rearrange the updating to s and s· and get É¿. Finally, we are able to
remove all temporary variables in stage 4, resulting in É , the optimized final code.
As É is about the same size of the source code, one might be tempted to program in
SimpleC directly. However, it is not sensible to make size the only gauge when compar-
ing programs written in different languages. As we have argued, E-FRP abstracts away
unnecessary details on evaluation order, offers a declarative view on behaviors, and some-
times eliminates code duplication. Therefore E-FRP is the preferred to SimpleC here.
139

É½ ÍncSpd ds ds·
· ½ ds·
ds µ
´DecSpd ds ds·
½ ds·
ds µ
´Stripe s s· · ½ s· s µ
ĆlkSlow s· ¼ dc if dc·
½¼¼ s ds then dc·
· ½
else if dc·
¼ s ds then dc·
½ else dc·
power count dc
s s· dc·
dc µ
ĆlkFast count if count·
½¼¼ then ¼ else count·
· ½
power count dc
count· count µ
É¾ ÍncSpd ds ds · ½ ds·
ds µ
´DecSpd ds ds ½ ds·
ds µ
´Stripe s s · ½ s· s µ
ĆlkSlow s· ¼ dc if dc ½¼¼ s ds then dc · ½
else if dc ¼ s ds then dc ½ else dc
power count dc
s s· dc·
dc µ
ĆlkFast count if count ½¼¼ then ¼ else count · ½
power count dc
count· count µ
É¿ ÍncSpd ds ds · ½ ds·
ds µ
´DecSpd ds ds ½ ds·
ds µ
´Stripe s s · ½ s· s µ
ĆlkSlow dc if dc ½¼¼ s ds then dc · ½
power count dc s ¼
s· s dc·
dc µ
power count dc
count· count µ
É ÍncSpd ds ds · ½ µ
´DecSpd ds ds ½ µ
´Stripe s s · ½ µ
ĆlkSlow dc if dc ½¼¼ s ds then dc · ½
power count dc s ¼ µ
power count dc µ
Figure 5.12: Optimization of the SRC controller
140

5.5 Translation from E-FRP to RT-FRP
Note that in È Á
È¼, È and È¼ have the same “structure.” Their only difference is in
the value of Ú’s in the init-in construct. Those Ú’s form the internal state of the program,
and the output of the program ( ) is determined by the input Á and the internal state.
Therefore a program È in E-FRP can be translated to an equivalent one in RT-FRP as a
group of mutually-recursive signals with a internal state.
In general, the program
È Ü ¾ÆÑ Ý init Ý¼ Ú in À ¾ÆÒ
translates to
let snapshot i input in
let snapshot ´Ý½ Ý·
½ ¡¡¡ ÝÒ Ý·
Ò µ
delay ´Ú½ Ú½ ¡¡¡ ÚÒ ÚÒµ ´ext µ
in ext ´ ½ ¡¡¡ Ñ Ý½ ¡¡¡ ÝÒµ
where is a function on ´Ý½ Ý·
½ ¡¡¡ ÝÒ Ý·
Ò µ which speciﬁes the next state of the program.
The current input i will be tested in to determine which event is occurring. When possi-
ble, some or all of the temporary variables Ý·
½ ¡¡¡ Ý·
Ò can be optimized away.
We will not describe how to derive from the source program È, which is possible but
tedious. Instead, we translate the SRC controller to RT-FRP as an example:
141

let snapshot i input in
let snapshot ´ds s dc countµ
delay ´¼ ¼ ¼ ¼µ
´ext ´if i IncSpd then
´ds · ½ s dc countµ
else if i Stripe then
´ds s · ½ dc countµ
else if i DecSpd then
´ds ½ s dc countµ
else if i ClkSlow then
´ds ¼ if dc ½¼¼ s ds then dc · ½
else if dc ¼ s ds then dc ½
else dc countµ
else if i ClkFast then
´ds s dc if count ½¼¼ then ¼ else count · ½µ
else
´ds s dc countµµµ
in ext ´ds s dc count if count dc then ½ else ¼µ
Unlike the translation from H-FRP to RT-FRP, which is an induction on the structure
of the program, this translation is not compositional since it involves topological sort and
therefore needs global information.
The existence of this translation shows that we can view E-FRP as roughly a subset of
RT-FRP.
142

5.6 Application in games
We have implemented a compiler for E-FRP in Haskell, as well as two back-ends for the
compiler. The ﬁrst back-end translates SimpleC to the C language the PIC16C66 C com-
piler accepts. Our second back-end generates code in an object-oriented language named
ICE [39], which is used to program robots in a computer simulation game called Min-
dRover [45].
As we have been using the Simple RoboCup controller as an example throughout
this chapter, the user should already have a good idea on how E-FRP works with micro-
controllers. Therefore, we devote this entire section to our interesting experiment on using
E-FRP in the MindRover game.
5.6.1 An introduction to MindRover
MindRover is a computer game developed by a company called CogniToy. In the game,
the player designs and programs vehicles to accomplish certain tasks, ranging from sports,
races, and maze solving to battles against other vehicles provided with the game or cre-
ated by other players. Once created, the vehicles are put into a simulated world to run on
their own. The game renders the scenario in 3-dimensional animation. Whether you can
beat the game depends on the vehicle you design and the controller you program for it.
To build a vehicle, you ﬁrst pick a chassis. There are three kinds to choose from:
hovercraft (driven by thrusters), wheeled (car-like), and treaded (tank-like); and there are
three sizes of each of them. The large chassis carries more components, but is also heavier
and requires more power to move. Obviously in a race heavier is bad. Hence the chassis
being chosen is vital for accomplishing the given scenario.
Next you add physical components to the chassis for the job at hand. There are two
major categories of them: sensors and actuators. The former category includes radar, sonar,
proximity sensor, bumper, radio receiver, and etc. The latter can be further divided into
movement (engine, thruster, steering wheel), communication (radio emitter, speaker) and
143

weapons (laser, machine gun, rocket launcher). You can decide the angle and location for
each component. A component has a certain point cost and weight associated with it, so
you cannot install unlimited number of them.
Finally, you need to program the vehicle. The details on this come in the next section.
For now, the reader just needs to know that MindRover has an event-driven model and
the control program of a vehicle amounts to handling various events picked up by the
sensors.
5.6.2 Programming vehicles in MindRover
Execution model
The simulated world in MindRover is object-oriented: a component is represented by an
object with properties accessible to the user program and the system. For example, a
radar object has an angle property that determines the direction of the radar, a scanWidth
property that speciﬁes how wide the “fan” of projection is, and a maxRange property for
the range it monitors. All these three properties can be read and set by the user program,
but there are properties that can only be read, for example sensor readings.
In MindRover, a vehicle interacts with its environment, or in general a component in-
teracts with other components, via event handlers. When an event occurs in the system
(for example, the radar sees something, the timer ticks, or a variable is changed), its han-
dler is executed, which may update some properties or trigger more events. When no
event occurs, the user program gets no control. Hence this is a event-driven system.
The game supports two ways for programming a vehicle: using a visual building tool
or writing the program in a textual language called ICE. Next we brieﬂy introduce both
of them.
144

The visual tool
The easier way of the two is to use the visual tool provided by the game. Suppose we are
designing a simple controller that does the following: when some component generates
an event , the ÓÓ property of component is set to some value Ú. We can do this in
the visual tool by drawing a wire (a directed edge) from to , right-clicking on the wire
and working with a drop-down box to set the triggeredBy property of the wire to , the
updateProperty property to ÓÓ, and the toValue property to Ú.
A wire can have only one source and one destination, and can carry only one action. If
we want to do more, more wires are required. For example, if we want to also set the Ö
property of component to Ú¼ on the same event, we repeat the above process, starting
with a wire from to .
The visual tool does not allow the user to write expressions directly. If some compu-
tation is involved to decide the value of a property, the user has to add logic components
(Boolean operators, arithmetic operators, variables, timers, and etc) to the system and
connect them to other components with wires.
Although the visual language is intuitive and easy to get started with, it is recom-
mended only for casual programming of simple controllers, for the following reasons:
1. Some functionalities are not easily accessible from the visual tool. For example,
Boolean operations, arithmetic, and variables all require adding new logic compo-
nents to the diagram, which soon gets clumsy.
2. Some functionalities of the system are not available at all in the visual tool. For
example some system objects can only be used in the ICE language.
3. For a complex controller, too many wires will present in the diagram, obscuring the
structure of the system.
4. The diagram does not tell the whole story. A large part of the meaning of a program
is hidden among the various properties of the wires and components, making it a
145

major effort to understand the system.
The ICE programming language
For serious programming, the other method is preferred, which is to write code in the ICE
language.
ICE is a simple object-oriented programming language that borrows its syntax from
Visual Basic. A vehicle controller in ICE mainly consists of an initializer and a bunch of
subroutines as event handlers. The user can also define auxiliary classes and functions. In
the initializer, the component objects are created and initialized (for physical components,
their positions on the chassis is also set), and the event handlers are registered with their
corresponding event sources.
While programming in ICE unleashes the full power of the system, it unfortunately
has some big problems too:
1. The ICE program is written in the event-handling approach, thus having all the
problems we have discussed in Section 5.1.3. In particular, ICE does not guarantee
a resource bound of the program. As an extreme example, an ICE program that has
a black hole will even cause the Windows operating system to hang.
2. ICE does not have a well-specified semantics. For example, many key aspects of
its execution mechanism is not documented and the ambiguity in the semantics is
often resolved in an ad hoc fashion. This makes understanding the program more
difficult and lowers the programmer’s confidence in a program.
5.6.3 From E-FRP to ICE
We notice that MindRover is an event-driven system, which is the domain of E-FRP. By
writing a back-end that translates SimpleC to ICE, we are able to use E-FRP to program
MindRover, and avoid the problems with programming in ICE.
146

We should point out that our work on combining E-FRP and MindRover is not just
for fun. Thanks to its simulation of physics, 3D-animation, and a vast selection of compo-
nents, MindRover provides an economic platform for us to build robotic vehicles and test
control algorithms on them. It also serves as a test bed for the applicability of our E-FRP
language.
Mapping between ICE and E-FRP
In ICE, events are generated by components, and the syntax Á is used for the event
Á generated by component . By allowing event names to contain “.”, ICE events map
directly to E-FRP events.
There are two kinds of properties in ICE: read-only and read-write. Read-only prop-
erties cannot be set by the user program and hence need no deﬁnitions; therefore they
are treated as external behaviors in E-FRP. Read-write properties can be updated by the
program, and are represented by a normal behavior in E-FRP.
Some behaviors (for example, temporary variables) in the E-FRP program do not cor-
respond to any component properties in ICE. For each such behavior, we allocate an ordi-
nary variable in ICE.
ICE has different syntaxes for assigning to a property and a non-property variable.
The former is done by
ÐÐ Ó Ø × ØÈÖÓÔ ÖØÝ´Ò ÛÎ ÐÙ µ
while the latter is simply
Ú Ö Ð Ò ÛÎ ÐÙ
Accordingly, the translation of a SimpleC assignment Ü to ICE depends on whether
Ü is an object property or not.
147

Extension to E-FRP for firing events
In E-FRP, the generation of events is outside of the model, and cannot be done within
the user program. Yet in MindRover, the ability to trigger events in the program is vital.
For example, in a battle scenario, the program need to fire a weapon, which is done by
triggering the weapon component’s Fire event.
We solve this problem by adding a small extension to E-FRP. Namely, we allow a
program to contain definitions of the following form:
Á trigger Á if
where is a stateless behavior of Boolean type. Such a definition means that event Á is
triggered when any event in Á occurs and the behavior is True. When True, the
definition can be written more concisely as
Á trigger Á
5.6.4 The KillerHover example
We end this section with an example in which a hovercraft is built to track down the op-
ponent and then kill it by launching rockets. We will use E-FRP to program the hovercraft,
but first we need to put all necessary physical components on the chassis. We are using
three radars, two thrusters, and one rocket launcher. The placement of these component
on the chassis is shown in Figure 5.13.
The E-FRP program controlling this vehicle is given by Figure 5.14.
The first three lines set up the front radar. By making the angle property ¼, we point
the radar to the front direction. In our example, the properties of the radar are all constant
numbers. In general, they can be behaviors that change over time, so it is possible to have
a rotating radar if that is desired.
The next six lines set up the left and the right radar.
148

chasis
rocketlauncher
left
radar
right
radar
front
radar
leftthruster
rightthruster
Figure 5.13: Structure of the Killer Hovercraft
149

fRadar.angle ¼
fRadar.scanWidth ¾¼
fRadar.maxRange ½¼
lRadar.angle ¼
lRadar.scanWidth ¾¼
lRadar.maxRange ½¼
rRadar.angle ¼
rRadar.scanWidth ¾¼
rRadar.maxRange ½¼
dir init Unknown in fRadar.TurnOn µFront
lRadar.TurnOn µLeft
rRadar.TurnOn µRight
lThruster.thrust if ´dir Leftµ then ¼
else ¼
rThruster.thrust if ´dir Unknown dir Rightµ then ¼
else ¼
fRadar.TurnOn trigger rocket.Fire
Figure 5.14: E-FRP program for the Killer Hovercraft
150

dir is a non-property behavior that represents the current direction of the opponent. It
is updated when any of the three radars detects the opponent and thus generates a TurnOn
event.
The thrust property of a thruster component determines the amount of power sent to
it. The left thruster (lThruster) and the right thruster (rThruster) are sent different amount
of power based on the current value of dir, making the vehicle to head for the opponent.
The last line says that the rocket should Fire when the front radar detects the opponent.
5.7 Discussion on later
In E-FRP, the user can specify the order in which behaviors are updated when an event
occurs, by annotating certain reactions with the later keyword. Yet the reader might have
noticed that RT-FRP does not have this feature. Instead, it has a delay construct which
might be used to achieve similar effect. A natural question to ask is why we invented
later when designing E-FRP, rather than just copying delay from RT-FRP. This section
discusses the ramiﬁcations of the design options we had and why we picked the current
one.
5.7.1 delay of RT-FRP
We could have used the delay construct from RT-FRP instead of the later annotation in
E-FRP. To do that, the syntax of E-FRP needs the following change:
Event handlers À Á µ
Stateful behaviors sf init Ü Ú in À
¬
¬ delay Ú
The rest of the syntax remains unchanged.
The semantics of init-in is the same as before except that we do not need to worry
151

about later reactions now. The semantics of delay can be given by:
È delay Ú
Á
¶ Ú
È
Á
¶ Ú¼
È delay Ú
Á
· delay Ú¼
This delay construct basically acts the same as its RT-FRP counterpart. However, in the
event-driven setting, it has a severe problem: a delay construct may behave differently in
different contexts, thus breaking the modularity of the system.
To illustrate the problem, we consider the following example:
heartbeat delay ¼ ´heartbeat · ½µ
This is the same À ÖØ Ø program we saw in Chapter 4, and it counts the number of
event occurrences in the system.
The problem is, heartbeat counts any event occurrences. If it is used in a system having
ﬁve events, it will count all of those ﬁve events; however, if we decide to add a module
that uses a sixth events to the system, suddenly heartbeat will count the occurrences of six
events — the meaning of this module is changed by the introduction of another module.
In general, when we design an event-driven system, we expect to be able to divide
them to modules that have different functionalities, implement the modules indepen-
dently, and then assemble these together. We also expect the function of a module is
not affected by other modules, so we can reason about the system compositionally. This
makes us believe the RT-FRP style delay is not a good construct for E-FRP.
5.7.2 A better delay
We notice that the shortcoming of delay can be remedied. In fact, the modularity problem
comes from the fact that we do not specify which events affect the delay construct. If
we do so, then adding events to the system will have no effect on the meaning a delay
construct.
152

This new delay construct has the syntax:
delay Ú on Á
where Á is the set of events that affect this behavior.
The semantics is given by:
È delay Ú on Á Á
¶ Ú
Á ¾ Á È Á
¶ Ú¼
· delay Ú¼ on Á
Á ¾ Á
· delay Ú on Á
However, we point out that this new delay is no more expressive than later, as it can
be expressed in terms of the latter. In general, the definition
Ü delay Ú on Á
can be replaced by the following definition using later:
Ý
Ü init Ú in Á µÝ later
where Ý is a fresh variable. Note that the translation works even when the original defini-
tion is recursive (i.e. when Ü occurs free in ).
Since delay can be defined using later, and our experience with micro-controllers
shows that the later construct is often easier to use, E-FRP is designed to have later but
no delay.
153

5.7.3 later as syntactic sugar
It might surprise the reader that the later annotation is not necessary even without delay!
In fact, any E-FRP behavior definition that uses later can be rewritten without later by a
simple translation, as long as the base language has pairs. More specifically, given
Ü init Ý Ú in Á µ Á µ later
we can rewrite it as
Ü¼ init Ý¼ ´Ú Úµ in Á µlet z Ý snd´Ý¼µ in ´z zµ
Á µ´snd´Ý¼µ Ý snd´Ý¼µ µ
Ü case Ü¼ of ´z µ µz
where Ü¼ and Ý¼ are fresh variables, and snd´ µ is syntactic sugar for
case of ´ zµ µz
Although later does not contribute to the expressiveness of E-FRP, having to revert to the
above trick often significantly obscures the program, and therefore we decided to keep
later in the language.
Chapter summary
We have presented a variant of RT-FRP called E-FRP that is suitable for event-driven real-
time reactive systems, and have shown how it can be compiled in a natural and sound
manner into a simple imperative language. We have implemented this compilation strat-
egy in Haskell. The prototype produces C code that is readily accepted by the PIC16C66
C compiler, and ICE code that can be used in the MindRover game. Our focus here is on
the feasibility of implementing this language and using it to program real event-driven
systems.
154

Chapter 6
Related work, future work, and
conclusions
6.1 Related work
6.1.1 Hybrid automata
As hybrid systems are increasingly used in safety-critical applications, the concept of a
hybrid automaton [22, 32] has been proposed as a formal model for reasoning about, and
verifying properties of, such systems. A hybrid automaton can be viewed as a generaliza-
tion of timed automata [2]. It has a finite number of control modes, in which the behavior of
variables is governed by a set of differential equations. Discrete events trigger the system
to jump from one mode to another. It has been shown that this concept is suitable for
specifying a large variety of hybrid systems, and methods have been developed to verify
interesting properties of certain categories of hybrid automata [1].
For a language to be used for hybrid reactive systems, the ability to express hybrid
automata is important. As we have shown, H-FRP is both resource-bounded and capable
of expressing hybrid automata directly using recursive integral behavior definitions and
recursive switching. Under the conditions we have identified in Section 4.5, an H-FRP
155

program can implement a hybrid automaton as the maximum sampling interval goes to
zero.
6.1.2 FRP
The work in this thesis is largely inspired by the Functional Reactive Programming (FRP)
language, which is designed for modeling and programming hybrid reactive systems.
FRP supports hybrid systems well by having both continuous-time-varying behaviors
and discrete events as first-class values. In particular, hybrid automata can be expressed
in FRP naturally.
FRP is an expressive language due to its extensive use of higher-order functions: sig-
nals can carry not only base type values like reals and Booleans, but also functions and
even signals; common programming pattern can also be abstracted as higher-order func-
tions. However, this flexibility is a double-edge sword, as it allows programs to use un-
limited amount of space and time, and even diverge. The combination of higher-order
functions and laziness makes reasoning about the cost of an FRP program extremely dif-
ficult in general. Thus FRP is not suitable for real-time systems. Nevertheless FRP has
been successfully applied in many domains that do not have hard real-time requirements,
including robotics [42] and animation [16].
RT-FRP is designed as a subset of FRP. While we keep RT-FRP small so that we can
easily study its properties, we have shown that many FRP constructs can be defined in
RT-FRP. We expect to translate a larger part of FRP to RT-FRP in the future.
Frappé [10] is an efficient implementation of a first-order subset of FRP. It translates
FRP constructs to Java. A number of interesting evaluation strategies (called push, pull,
and hybrid) have been explored in the context of Frappé and we are interested in for-
malizing these models and studying their properties. Frappé uses double-buffering in
the translation, which is similar to our use of temporary variables in compiling E-FRP
programs.
156

6.1.3 Synchronous data-flow languages
RT-FRP can be categorized as a synchronous data-flow language. Before RT-FRP, several
other languages have been proposed around the synchronous data-flow notion of compu-
tation, including SIGNAL [18], LUSTRE [7], and ESTEREL [6, 4]. We will discuss the features
of these languages and their connection with RT-FRP one by one.
Synchronous languages can be classified into imperative ones and declarative ones. The
former defines a reactive system as a state-transition machine and specifies an explicit
sequence of steps to follow to make a reaction. The latter defines a reactive system by
specifying the relations between a set of signals using functions or constraints. Although
an RT-FRP program describes a state machine, it does so by specifying the relations be-
tween the sub-components. Therefore we consider RT-FRP a declarative language.
In general, a system using recursive switching may use unbounded stacks. Hence, to
achieve reactivity, none of the synchronous data-flow reactive languages has considered
recursive switching. RT-FRP improves on them by allowing a restricted form of recursive
switching.
RT-FRP clearly separates the base language and the reactive language and gives the
user the choice on what is the best base language for the job at hand. This is not done
in those synchronous reactive languages. We have found that such a separation makes
RT-FRP more flexible, and helps us to clearly understand the two languages’ individual
contributions to the cost of execution.
ESTEREL
Reactive systems whose main purpose is to continuously produce output values from
input ones are called data-dominated, and those focus on producing discrete output from
input signals are said to be control-dominated. ESTEREL is a synchronous imperative lan-
guage devoted to programming control-dominated software or hardware reactive sys-
tems [6].
157

Compilers are available that translate ESTEREL programs into finite state machines or
digital circuits for embedded applications. These compilers perform heavy optimizations
and can generate very efficient code, making ESTEREL a good choice for hardware design
and performance-critical systems. In relation to our current work, a large effort has been
made to develop a formal semantics for ESTEREL, including a constructive behavioral
semantics, a constructive operational semantics, and an electrical semantics (in the form
of digital circuits). These semantics are shown to correspond in a certain way, constrained
only by a notion of stability.
ESTEREL does not handle data-processing well, and thus is not suitable for data-dominated
systems. In contrast, RT-FRP supports both behaviors and events naturally, and can be
used for both data-dominated and control-dominated systems.
SIGNAL
SIGNAL [18] is a synchronous declarative language, where the central concept is a signal,
a time-ordered sequence of values. This is analogous to the sequence of values generated
in the execution of an RT-FRP program. Unlike in most other languages, a SIGNAL pro-
gram is a set of constraints on signals, and the meaning of the program is the solution
to the constraints. When two components are composed, the meaning of the composite
component is the solution to the union of the constraints of the sub-components.
To verify a certain property of a program, the user can encode the property as SIGNAL
equations. It could be then checked whether such equations are already implied by the
program, or the equations may be simply added to the program to make sure the property
is satisfied at run time. This is an important feature of SIGNAL.
Given a SIGNAL program (i.e. a set of constraints on signals), a solution for the con-
straints may not exist, in which case the system is undefined. It could also happen that
more than one solutions can be found, in which case the system is non-deterministic. In
general, it is mentally challenging for the programmer to find the solution for a program
and determine whether it is unique. Therefore SIGNAL programs can be difficult to un-
158

derstand and maintain.
In contrast, RT-FRP specifies the relations between signals by functions rather than
constraints. Hence RT-FRP programs are easier to understand than those written in SIG-
NAL. However, RT-FRP does not directly support verification of program properties. We
plan to investigate the possibility of adding a SIGNAL-style verification mechanism to
RT-FRP.
LUSTRE
LUSTRE is a language similar to SIGNAL, rooted again in the notion of a sequence. Unlike
SIGNAL, LUSTRE programs define signals by functions and thus are deterministic. The
LUSTRE formalism is very similar to temporal logics, so it can also be used for expressing
program properties. A verification tool is implemented such that given a program with a
single Boolean output, it checks that the output is never False. There is no fundamental
difficulty in using the same approach for verifying properties of RT-FRP programs, and
we are looking into such possibilities.
Synchronous Kahn networks
Caspi and Pouzet noticed the lack of expressiveness of synchronous data-flow reactive
languages and proposed Synchronous Kahn networks [8], which extended these lan-
guages with recursive switching and higher-order programming, yielding a large increase
in expressive power. While Synchronous Kahn networks still are synchronous, resource-
boundedness is no longer guaranteed.
The expressiveness of RT-FRP lies somewhere between synchronous data-flow reac-
tive languages and Synchronous Kahn networks: it supports recursive switching, yet at
the same time manages to achieve a bound in space and response time using some syn-
tactic restrictions and a type system.
159

6.1.4 SAFL
Mycroft and Sharp develop a statically allocated parallel functional language SAFL [37]
for the specification of hardware. Their language allows recursion, but restricts recursive
calls to tail calls. The purpose for such restriction is to be able to allocate all variables
to fixed storage locations at compile time, which is essential for hardware design. As a
result, the total space required for executing a program is Ç´length of programµ.
As we are interested in using RT-FRP for real-time software systems, what is important
is that there exists a bound for the space needed during program execution, not that all
variables are allocated statically. Indeed, an RT-FRP program can allocate space dynami-
cally, but the type system limits how much space it can consume at most. In the extreme
case, a program can use exponential space with respect to the program size. This relax-
ation allows more programs to be expressed. In particular, it makes finite automata easy
to encode.
SAFL uses an explicit notion of a syntactic context to specify what is a tail call, and
restrict recursive functions. In our work, we have integrated this restriction into the type
system. It will be interesting to see an integration is also possible in their setting.
6.1.5 Multi-stage programming
There are many connections between the semantics of RT-FRP and the semantics of multi-
stage languages. Evaluating recursive let-snapshot declarations requires evaluation un-
der a binder. This problem arises constantly in the context of multi-level and multi-stage
languages [48]. Our approach to the treatment of this problem, namely, splitting the vari-
able context into current variables and later variables in the type system, is inspired by
the work on multi-stage languages [34, 50]. Our evaluation and updating functions are
also analogous to the evaluation and rebuilding functions of multi-stage language [48].
160

6.1.6 SCR
The SCR (Software Cost Reduction) requirements method [20] is a formal method based
on tables for specifying the requirements of safety-critical software systems. SCR is sup-
ported by an integrated suite of tools called SCR* [21], which includes among others a con-
sistency checker for detecting well-formedness errors, a simulator for validating the specifi-
cation, and a model checker for checking application properties. SCR has been successfully
applied in some large projects to expose errors in the requirements specification. We have
noticed that the tabular notation used in SCR for specifying system behaviors has a simi-
lar flavor as that of E-FRP, and it would be interesting future work to translate E-FRP into
SCR and hence leverage the SCR* tool set to find errors in the program.
6.2 Future work
6.2.1 Clocked events
FRP and H-FRP have the lifting operators, which allow us to build a behavior by applying
a function pointwise to a group of behaviors. In RT-FRP, such operators can be defined as
syntactic sugar.
Sometimes, we know that certain events have the same occurrence pattern (i.e. one
event occurs if and only if the other occurs), in which case we can apply a function to
their occurrence values pointwise and get a composite event that has the same pattern. In
other words, we want to write events in the form of
lift Ú½ Ú¾
where Ú½ and Ú¾ are known to be “in sync.” For reliability of the system, we want to
reject the above expression at compile time if Ú½ and Ú¾ cannot be shown to always
occur simultaneously.
In FRP, we call the occurrence pattern of an event its clock. Independent events are
161

deemed to have different clocks, while events that provably always occur together are
said to share the same clock. For example, event mapping preserves the clock of its event
operand. The clock is part of the type of an event. An event of type « with clock Æ has
type signature E Æ «. Hence events with different clocks have different type signatures.
In lift Ú½ Ú¾, the lift operator has type
´« ¬ µ E Æ « E Æ ¬ E Æ
The type ensures that the Ú½ and Ú¾ have the same clock Æ, and so does the result.
While in general whether two events have the same occurrence pattern is undecidable,
we would like the clock inference to be as accurate as possible. In particular, we want the
system to know that ½ ¾ (an event that occurs whenever either ½ or ¾ occurs) and
¾ ½ have the same clock, while ½ ¾ and ½ ¿ do not (assuming that ¾ and
¿ have different clocks). Although it is not difficult to design a type system to convey
this idea, we are not able to implement it for FRP since FRP is embedded in Haskell and
therefore inherits Haskell’s type system. As a result, the clocked events scheme in FRP is
compromised.
For simplicity, RT-FRP as presented in this thesis does not support clocked events,
which we expect to incorporate as future work. Since RT-FRP is a stand-alone language,
we will be able to implement for it a type system that inferences clocks more accurately
that the FRP type system does.
6.2.2 Arrow
When defining a large reactive system, it is often possible to divide the whole system
into several inter-connected sub-systems that are driven by different types of stimuli, and
define them individually. Such modular definitions are often easier to come up with and
understand.
Yet, within an RT-FRP program, all components must have the same type of input
162

(i.e. the Input type is fixed across the program). This restriction is not compatible with the
divide-and-conquer approach. Hence we would like to propose a method for combining
RT-FRP machines with different stimulus types.
Courtney, Nilsson and Peterson suggest that Hughes’ arrows [27] provide a natural
mechanism for modeling signals that are explicitly parameterized by an input type. The
benefits of the arrow framework include better modularity and reduced space leak. They
have designed a version of FRP [38] in this framework, and the utility of this language has
been confirmed in the setting of robotics [41]. We expect that this approach can be used as
a basis for a language for combining RT-FRP machines.
6.2.3 Better models for real-time systems
In this thesis, we have chosen to focus on the issue of bounded resources in the presence of
recursion. Ultimately, however, we are interested in more sophisticated models for real-
time systems, where resources are allocated according to their priority (see Kieburtz [30]
for a nice account from the Haskell point of view). SIGNAL, LUSTRE, and synchronous
Kahn networks [8] account for this via a clock calculus, which allows different parts of the
system to run at different frequencies. While this technique may apply directly to RT-FRP,
this still remains to be established.
Arrows also provide a way for combining computation performed at different fre-
quencies, through its ArrowChoice operator [40]. It remains to be investigated whether
this or the clock calculus is a better solution.
6.2.4 Parallel execution
The operational semantics of RT-FRP relegates all actual computations to the base lan-
guage. Since we require the base language to be pure, the order in which expressions
are evaluated does not affect the result of an RT-FRP program. In particular, indepen-
dent expressions can be evaluated concurrently. As Hammond [19] observes, “it is almost
163

embarrassingly easy to partition a program written in a strict [functional] language [into
parallel threads].” We expect to be able to develop such a partitioning strategy for RT-FRP
programs.
6.3 Conclusions
We have designed a language RT-FRP for real-time reactive systems. Programs written
in this language are guaranteed to consume bounded space and time for each reaction.
RT-FRP improves on synchronous data-ﬂow reactive languages by allowing recursive
switching to be expressed. H-FRP and E-FRP, two variants of RT-FRP, are developed to
better suit the need for programming hybrid systems and event-driven systems. These
languages improve on traditional languages for their respective domains.
Our theoretical results include formal proofs for the resource-boundedness of RT-FRP,
a set of conditions under which the discrete execution of an H-FRP program converges to
its continuous semantics, and a provably correct compiler for E-FRP.
The applicability of our approach has been tested in the context of micro-controllers
and computer-simulated robotics.
164

Appendix A
Proof of theorems
A.1 Theorems in Chapter 3
Lemma 3.4. × is defined for all ×.
Proof. By induction on ×.
1. × input, time, or ext . By the definition of , we have that × is defined.
2. × delay ×¼. By the induction hypothesis, ×¼ is defined. Therefore × ¾ · ×¼ is
defined.
3. × let snapshot Ü ×½ in ×¾. By the induction hypothesis, ×½ and ×¾ are defined.
Therefore × ¾ · ×½ · ×¾ is defined.
4. × let signal Þ ´Ü µ Ù ¾ÆÒ in ×¼. By the induction hypothesis, ×¼ is defined,
and for all ¾ÆÒ, Ù is defined. Therefore × ½ · ¾Ò · ¦
Ò
½ Ù · ×¼ is defined.
5. × ×¼ until × µ Þ ¾ÆÒ . By the induction hypothesis, ×¼ is defined, and for all
¾ÆÒ, × is defined. Therefore × ½ · Ò · ×¼ · ¦
Ò
½ × is defined.
And we are done.
Lemma 3.5. For all term × and integer Ñ, × Ñ is defined.
165

Proof. By induction on ×. Given a term ×, we assume that for all sub-term ×¼ in ×, ×¼
Ñ is
defined for all integer Ñ.
1. × input, time, or ext . By the definition of Ñ, × Ñ is defined.
2. × delay ×¼. By the induction hypothesis, ×¼
Ñ is defined. Therefore × Ñ
¾ · ×¼
Ñ is defined.
3. × let snapshot Ü ×½ in ×¾. By the induction hypothesis, ×½ Ñ and ×¾ Ñ are
defined. Therefore × Ñ ¾ · ×½ Ñ · ×¾ Ñ is defined.
4. × let signal Þ ´Ü µ Ù ¾ÆÒ in ×¼. By the induction hypothesis, for all ¾ ÆÒ,
Ù ¼ is defined. Therefore

Þ Ü Ù ¾ÆÒ

Ñ Ü ¼
¨
Ù ¼
© ¾ÆÒ
is defined. Hence Ñ Ü Ñ is defined, and by the induction hypothesis ×¼
Ñ Ü Ñ
is defined. Therefore, × Ñ ½ · ¾Ò · ¦
Ò
½ Ù · ×¼
Ñ Ü Ñ is defined.
5. × ×¼ until × µÞ ¾ÆÒ . By the induction hypothesis, ×¼
¼ is defined, and for all
¾ÆÒ, × ¼ is defined. Therefore × Ñ ½ · Ò · ×¼
¼ · ¦
Ò
½ × ¼ is defined.
And we are done.
Lemma 3.6. For all term × and integer Ñ, × × Ñ.
Proof. By induction on ×. Given a term ×, we assume that for each sub-term ×¼ of ×, ×¼
×¼
Ñ for all integer Ñ.
1. × input, time, or ext . By the definition of and Ñ, we have × × Ñ.
2. × delay ×¼.
× ¾ · ×¼
¾ · ×¼
Ñ (Induction hypothesis)
× Ñ
166

3. × let snapshot Ü ×½ in ×¾.
× ¾ · ×½ · ×¾
¾ · ×½ Ñ · ×¾ Ñ (Induction hypothesis)
× Ñ
4. × let signal Þ ´Ü µ Ù ¾ÆÒ in ×¼.
× ½ · ¾Ò · ¦
Ò
½ Ù · ×¼
½ · ¾Ò · ¦
Ò
½ Ù · ×¼
Ñ Ü Þ Ü Ù ¾ÆÒ Ñ (Induction hypothesis)
× Ñ
5. × ×¼ until × µÞ ¾ÆÒ .
× ½ · Ò · ×¼ · ¦
Ò
½ ×
½ · Ò · ×¼
¼ · ¦
Ò
½ × ¼ (Induction hypothesis)
Ñ Ü ½ · Ò · ×¼
¼ · ¦
Ò
½ × ¼ Ñ
× Ñ
And we are done.
Lemma 3.7. ×
Ø
×¼ implies ×¼ × .
Proof. The proof is by induction on the derivation for ×
Ø
×¼. In what follows,
we let Ñ .
1. The last rule used in the derivation is u1, u2, or u3. In this case × ×¼. Hence
×¼
Ñ × Ñ.
2. The last rule in the derivation is u4. Then × delay Ú ×½, ×¼ delay Ú¼ ×¼
½, and
167

×½
Ø
×¼
½. By induction hypothesis,

×¼

Ñ ¾ ·

×¼
½

Ñ ¾ · ×½ Ñ × Ñ
3. The last rule is u5. We have that × let snapshot Ü ×½ in ×¾, ×¼ let snapshot Ü
×¼
½ in ×¼
¾, ×½
Ø
¸ Ú½, Ü Ú½ ×½
Ø
×¼
½, and Ü Ú½ ×¾
Ø

×¼
¾. Therefore
×¼
Ñ ¾ · ×¼
½ Ñ · ×¼
¾ Ñ
¾ · ×½ Ñ · ×¾ Ñ (Induction hypothesis)
× Ñ
4. The last rule is u6. We know that
× let signal Þ ´Ü µ Ù in ×½
×¼ let signal Þ ´Ü µ Ù in ×¼
½
and Þ Ü Ù ×½
Ø
×¼
½
Note that
Þ Ü Ù
Ñ Ü Ñ Ü Ù ¼ Ñ
Ñ Ü Þ Ü Ù Ñ
Hence,
×¼
Ñ
½ · ¾Ò · ¦
Ò
½ Ù · ×¼
½ Ñ Ü Þ Ü Ù Ñ
½ · ¾Ò · ¦
Ò
½ Ù · ×½ Ñ Ü Þ Ü Ù Ñ (Induction hypothesis)
× Ñ
168

5. The last rule is u7. In this case,
× ×¼ until × µÞ ¾ÆÒ
and ×¼ Ù Ü Ú , where ´Þ Ü Ùµ ¾ for some Þ and Ü.
×¼
Ñ
Ù Ñ
Ñ Ü ½ · Ò¼ · ×¼
¼ ¼ · ¦
Ò¼
½

×¼

¼
Ñ
where Ù ×¼
¼ until ×¼ µÞ¼ ¾ÆÒ¼
Ñ Ü ½ · Ò¼ · ×¼
¼ ¼ · ¦
Ò¼
½

×¼

¼
¼ Ñ
Ñ Ü Ù ¼ Ñ
Ñ (´Þ Ü Ùµ ¾ and Ñ )
Ñ Ü
Ò
½ · Ò · ×¼ ¼ · ¦
Ò
½ × ¼ Ñ
Ó
× Ñ
6. The last rule is u8. We have that × ×¼ until × µ Þ ¾ÆÒ , ×¼ ×¼
¼ until ×¼ µ
Þ ¾ÆÒ , and
Ò
×
Ø
×¼
Ó ¾ ¼ Ò
. Therefore
×¼
Ñ Ñ Ü
Ò
½ · Ò · ×¼
¼ ¼ · ¦
Ò
½

×¼

¼
Ñ
Ó
Ò
½ · Ò · ×¼ ¼ · ¦
Ò
½ × ¼ Ñ
Ó
(Induction hypothesis)
× Ñ
And we are done.
Lemma 3.8. For any term × and integer Ñ ¼, we have that × Ñ Ñ Ü ½ Ñ ¡¾
× .
Proof. By induction on ×. We assume that for any sub-term ×¼ of ×, we have ×¼
Ñ
Ñ Ü ½ Ñ ¡¾
×¼
for all integer Ñ ¼.
169

1. × input or time. We have
× Ñ ½
Ñ Ü ½ Ñ ¡¾
½
Ñ Ü ½ Ñ ¡¾
×
2. × ext . We have
× Ñ ¾
Ñ Ü ½ Ñ ¡¾
¾
Ñ Ü ½ Ñ ¡¾
×
3. × delay ×¼. It follows that
× Ñ ¾ · ×¼
Ñ
¾ · Ñ Ü ½ Ñ ¡¾
×¼
Ñ Ü ½ Ñ ¡¾
¾· ×¼
Ñ Ü ½ Ñ ¡¾
×
4. × let snapshot Ü ×½ in ×¾. We have
× Ñ ¾ · ×½ Ñ · ×¾ Ñ
¾ · Ñ Ü ½ Ñ ¡¾
×½ · Ñ Ü ½ Ñ ¡¾
×¾
Ñ Ü ½ Ñ ¡¾
¾· ×½ · ×¾
Ñ Ü ½ Ñ ¡¾
×
170

5. × let signal Þ ´Ü µ Ù ¾ÆÒ in ×¼. We have
× Ñ ½ · ¾Ò · ¦
Ò
½ Ù · ×¼
Ñ Ü Þ Ü Ù ¾ÆÒ Ñ
½ · ¾Ò · ¦
Ò
½ Ù · ×¼
Ñ Ü Ñ
where

Þ Ü Ù ¾ÆÒ

Ñ Ü ¼
¨
Ù ¼
© ¾ÆÒ
½ · ¾Ò · ¦
Ò
½ Ù · Ñ Ü
¨
¾
Ù © ¾ÆÒ
Ñ ¡¾
×¼
(Induction hypothesis) ´£µ
We want to prove that ´£µ ´ µ, where ´ µ Ñ Ü ½ Ñ ¡ ¾
½·¾Ò·¦Ò
½ Ù · ×¼
Ñ Ü ½ Ñ ¡¾
× . There are three cases:
(a) Ò ¼. We have
´£µ ½ · Ñ ¡¾
×¼
¾
×¼
· Ñ ¡¾
×¼
´Ñ Ü ½ Ñ · Ñ Ü ½ Ñ µ ¡¾
×¼
´ µ
(b) Ò ½ and Ñ Ñ Ü
¨
¾
Ù © ¾ÆÒ
. We have
´£µ ½ · ¾Ò · ¦
Ò
½ Ù · ¾
Ñ Ü Ù ¾ÆÒ· ×¼
¾
½·¾Ò·¦Ò
½ Ù · ¾
Ñ Ü Ù ¾ÆÒ· ×¼
¾
½·¾Ò·¦Ò
½ Ù · ¾
¾Ò·¦Ò
½ Ù · ×¼
¾
¾Ò·¦Ò
½ Ù · ×¼
· ¾
¾Ò·¦Ò
½ Ù · ×¼
¾
½·¾Ò·¦Ò
½ Ù · ×¼
´ µ
171

(c) Ò ½ and Ñ Ñ Ü
¨
¾
Ù © ¾ÆÒ
. Hence Ñ ¾. We have
´£µ ½ · ¾Ò · ¦
Ò
½ Ù · Ñ ¡¾
×¼
½ · ¾Ò · ¦
Ò
½ Ù · Ñ ¡¾
¾Ò·¦Ò
½ Ù · ×¼
¾
½·¾Ò·¦Ò
½ Ù · Ñ ¡¾
¾Ò·¦Ò
½ Ù · ×¼
Ñ ¡¾
½·¾Ò·¦Ò
½ Ù · Ñ ¡¾
¾Ò·¦Ò
½ Ù · ×¼
Ñ ¡¾
¾Ò·¦Ò
½ Ù · ×¼
· Ñ ¡¾
¾Ò·¦Ò
½ Ù · ×¼
´ µ
6. × ×¼ until × µÞ ¾ÆÒ . We have
× Ñ Ñ Ü
Ò
½ · Ò · ×¼
¼ · ¦
Ò
½ × ¼ Ñ
Ó
. We want to prove that
× Ñ Ñ Ü ½ Ñ ¡¾
×
It sufﬁces to prove that
½ · Ò ·

×¼

¼
· ¦
Ò
½ × ¼ Ñ Ü ½ Ñ ¡¾
×
and
Ñ Ñ Ü ½ Ñ ¡¾
×
The latter is trivial. Now we try to prove the former:
½ · Ò · ×¼
¼ · ¦
Ò
½ × ¼ ½ · Ò · ¾
×¼
· ¦
Ò
½¾
× (Induction hypothesis)
¾
½·Ò· ×¼ ·¦Ò
½ × (See comments below.)
¾
×
Ñ Ü ½ Ñ ¡¾
×
172

The step
½ · Ò · ¾
×¼
· ¦
Ò
½¾
× ¾
½·Ò· ×¼ ·¦Ò
½ ×
is proved by noticing that there are two cases:
(a) Ò ¼. We have
½ · Ò · ¾
×¼
· ¦
Ò
½¾
× ½ · ¾
×¼
¾
½· ×¼
¾
½·Ò· ×¼ ·¦Ò
½ ×
(b) Ò ½. In this case we have
½ · Ò · ¾
×¼
· ¦
Ò
½¾
× ¾
½·Ò · ¾
×¼
· ¦
Ò
½¾
×
¾
½·Ò · ¾
×¼
· ¾
¦Ò
½ ×
¾
½·Ò· ×¼ ·¦Ò
½ ×
To ease the proof of the theorems, ﬁrst we prove the following causality lemma, which
states that the responses of the system has made so far do not depend on the future:
Lemma A.1 (Causality). Given an H-FRP term ¾ Î and an environment where
, for any time sequence È Ø½ Ø¾ ¡¡¡ ØÒ , let Ú½ Ú¾ ¡¡¡ ÚÒ trace ´ µ È, we
have that
¾ÆÒ trace Ø½ ¡¡¡ Ø Ú½ ¡¡¡ Ú
Proof. By the deﬁnition of trace .
Theorem 4.2 (Time). time µ at time ÈØ Ø
¬
¬
½
Ø¼
.
173

Proof. Following the operational semantics, we have
trace time ÈØ ÈØ
Therefore
at time ÈØ Ø
and it follows by the deﬁnition of uniform convergence that
at time ÈØ Ø
¬
¬
½
Ø¼
Theorem 4.3 (Input). input µ at input ÈØ ÒÔÙØ´Øµ
¬
¬
½
Ø¼
.
Proof. Following the operational semantics, we have
trace input Ø½ ¡¡¡ ØÒ ÒÔÙØ´Ø½µ ¡¡¡ ÒÔÙØ´ØÒµ
Therefore
at input ÈØ ÒÔÙØ´Øµ
and it follows by the deﬁnition of uniform convergence that
at input ÈØ ÒÔÙØ´Øµ
¬
¬
½
Ø¼
Theorem 4.4 (Lift). Given lift ´ ´Ü½ ¡¡¡ ÜÒµ µ ½ ¡¡¡ Ò, if we have:
1. ,
2. ´Ý½ ¡¡¡ ÝÒµ eval Ü Ý is uniformly continuous, and
174

3. ¾ÆÒ at ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë ,
then
¬
¬
¬
Ì
Ø¼

Ò
½
Ë
Proof. Let at , ´Ý½ ¡¡¡ ÝÒµ eval Ü Ý , and À at . There are two
cases to consider:
1. Ò ¼. À´ÈØµ eval . It follows trivially that
¬
¬
¬
Ì
Ø¼

Ò
½
Ë
2. Ò ¼. For any given ¯ ¼, since is uniformly continuous, there is a Æ ¾´¼ ¯µ such
that
¬
¬ Ú Ú¼ ¬
¬ Æ µ ¬
¬ ´Úµ ´Ú¼µ
¬
¬ ¯
For any ¾ÆÒ, since ´ÈØµ ´Øµ
¬
¬Ì
Ø¼
Ë , we have that there is ¼ such that
Ø ¾ ¼ Ì Ë Æ Ò and
¬
¬ÈØ
¬
¬
Ø¼
imply
¬
¬ ´ÈØµ ´Øµ
¬
¬ Æ Ò. Let Ñ Ò ,
then for any ¾ÆÒ, Ø ¾ ¼ Ì Ë Æ Ò and
¬
¬ÈØ
¬
¬
Ø¼
imply
¬
¬ ´ÈØµ ´Øµ
¬
¬ Æ Ò.
Since Æ Ò ¯ Ò ¯, we have ¾ ÆÒ ¼ Ì ËÒ
½ Ë
¯
¼ Ì Ë Æ Ò ,
and therefore Ø ¾ ¼ Ì ËÒ
½ Ë
¯
and
¬
¬ÈØ
¬
¬
Ø¼
imply that
¬
¬ ´ ½´ÈØµ ¡¡¡ Ò´ÈØµµ ´ ½´Øµ ¡¡¡ Ò´Øµµ
¬
¬ Æ
This in turn leads to
¬
¬ ´ ½´ÈØµ ¡¡¡ Ò´ÈØµµ ´ ½´Øµ ¡¡¡ Ò´Øµµ
¬
¬ ¯.
By the operational semantics of lift, we have À´ÈØµ ´ ½´ÈØµ ¡¡¡ Ò´ÈØµµ. There-
fore we have established that
¯ ¼ ¼ ´Ø ¾ ¼ Ì ËÒ
½ Ë
¯
and
¬
¬ÈØ
¬
¬
Ø¼
µ µ
¬
¬ À´ÈØµ ´ ½´Øµ ¡¡¡ Ò´Øµµ
¬
¬ ¯
175

Hence
¬
¬
¬
Ì
Ø¼

Ò
½
Ë
The following two lemmas are needed for proving Theorem 4.5. Lemma A.2 says that
if is integrable on a closed interval Á, then it is also integrable on sub-intervals of Á.
Lemma A.3 establishes a further property: if if integrable on a closed interval Á, then
the sum-of-the-areas uniformly converge to the integral of on sub-intervals of Á.
Lemma A.2. For all , we have
´ µ µ ´ µ
Lemma A.3. Given a function and real numbers , if
Ê
´ µ , we have that
for all ¯ ¼, there is Æ ¼, such that
and È Ø½ ¡¡¡ ØÒ È Æ µ¬
¬
¬¦
Ò ½
½ ´ µ¡Ø Ê
´ µ
¬
¬
¬ ¯
where is arbitrarily chosen from the interval Ø Ø ·½ .
Proof (Lemma A.2). Let
Ê
´ µ .
For any given ¯½ ¼, since , by the deﬁnition of Riemann integral, we know
that there is Æ½ ¼ such that for all È Ø½ ¡¡¡ ØÒ where Ø½ Ø¾ ¡¡¡ ØÒ , if
È Æ½, we have
¬
¬
¬¦
Ò ½
½ ´ µ¡Ø
¬
¬
¬ ¯½
where is arbitrarily chosen from the interval Ø Ø ·½ .
We can choose È such that it contains the point and , i.e. there are Ñ ¾ÆÒ giving
176

us ØÑ and Ø . Obviously, ½ Ñ Ò. Then we rewrite the above formula as
¬
¬
¬¦
Ñ ½
½ ´ µ¡Ø · ¦
½
Ñ ´ µ¡Ø · ¦
Ò ½
´ µ¡Ø
¬
¬
¬ ¯½
Let ¦
Ñ ½
½ ´ µ¡Ø · ¦
Ò ½
´ µ¡Ø and ¦
½
Ñ ´ µ¡Ø . The above can be
further rewritten as
· ¯½
For any non-empty non-descending sequence É ½ ¡¡¡ Ð , where ½ and
Ð , and É Æ½, it is obvious that the norm of Ø½ ¡¡¡ ØÑ ½ ·· É ·· Ø ¡¡¡ ØÒ is also
less than Æ½. Thus we have
¬
¬ ·
¼¬
¬ ¯½
where ¼ ¦
Ð ½
½ ´ µ¡ and is arbitrarily chosen from ·½ .
Then we can see that the difference between ¼ and is bounded by ¾¯½:
¬
¬ ¼ ¬
¬
¬
¬´ ·
¼µ ´ · µ
¬
¬
¬
¬ ·
¼¬
¬ · · ¾¯½
In other words, letting interval Á½ ¾¯½ · ¾¯½ , for any non-empty non-
descending sequence É ¡¡¡ , where É Æ½, we have that
´Éµ ¾Á½
where ´Éµ is the notation we adopt from now on 1 for
¦
Ð ½
½ ´ µ¡ where ½ ¡¡¡ Ð É and is arbitrarily chosen from ·½ .
Next, we pick an ¯¾ ¼. By the same reasoning, we know that there is Æ¾ ¾ ´¼ Æ½µ,
such that for any non-empty non-descending sequence É ¡¡¡ , where É Æ¾,
1
The reader must remember that is not to be treated as a function, since it is not. Instead, we should
regard ´Éµas an (atomic) shorthand for the above expression.
177

we have that
´Éµ ¾Á¾
where we arbitrarily choose a É¾ satisfying the above requirements and let ¾ ´É¾µ,
and Á¾ ¾ ¾¯¾ ¾ · ¾¯¾ .
Obviously, ¾ ¾Á¾. At the same time, since É¾ Æ½, we know that ¾ ´É¾µ ¾Á½.
Given an (infinite) series of positive real numbers ¯½ ¯¾ ¡¡¡, by repeating the above
reasoning, we can establish that for all ¾, we can find a Æ ¾´¼ Æ ½µ (depending only
on ¯ ), such that for all É ¡¡¡ where É Æ , we have
´Éµ ¾Á
where we arbitrarily choose a É satisfying the above requirements and let ´É µ,
and Á ¾¯ · ¾¯ . Besides, we know ¾Á½ ¡¡¡ Á .
Let Â Á½ ¡¡¡ Á for all ¾Æ. Since ¾Â , we know Â is not empty. Furthermore,
for all ¾Æ, we have Â is a closed interval enclosing Â ·½.
Since Â Á and the length of Á is ¯ , we know the length of Â is no more than ¯ .
By choosing the series ¯½ ¯¾ such that ¯ tend to zero (for example, ¯ ¾
), we
can make the lengths of Â tend to zero. In this case, Â½ Â¾ are called a nested sequence
of intervals [9, page 8].
Now recall the axiom of continuity (also known as the axiom of nested intervals) for real
numbers [9, page 8,95], which says “if Â½ Â¾ form a nested sequence of intervals, there
is a unique point Ü ¾Ê contained in all Â .” Therefore, there is a unique Ü ¾Ê contained
in all Â . By the definition of Riemann integral,
Ê
´ µ Ü . And we are done.
Proof (Lemma A.3). The proof is easy once we understand the proof for Lemma A.2.
Given ¯ ¼, let ¯ . By the same reasoning as in the proof for Lemma A.2, we
know there is Æ ¼ (depending only on ), such that for all non-empty non-descending
178

sequence È Ø½ ¡¡¡ ØÒ where Ø½ Ø¾ ¡¡¡ ØÒ ,
È Æ µ
¬
¬
¬
¬
¦
Ò ½
½ ´ µ¡Ø ´ µ
¬
¬
¬
¬
¯
where is arbitrarily chosen from Ø Ø ·½ . And we are done.
Theorem 4.5 (Integral). If
1. integral ,
2. at ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë where Ë is ﬁnite, and
3. there is Ì¼ Ð Ø¼ such that
(a) for all time sequence ÈØ Ø½ ¡¡¡ Ø where Ì¼ Ø½ Ø Ì, at ÈØ is
bounded,
(b) ´Øµ is bounded on Ì¼ Ì , and
(c)
Ê Ì
Ì¼
´Øµ Ø ,
then we have
at integral ÈØ
Ø
Ø¼
´ µ
¬
¬
¬
¬
Ì
Ø¼
Proof. Let at . Since is bounded, there is a Ã ¼ such that
¬
¬ ´ÈØµ
¬
¬ Ã for all
ÈØ.
Since Ë is ﬁnite, we can let Ì½ ¡¡¡ Ì Ë for some ¾Æ.
Given ¯ ¼, let
¯ ¾
´¿ · ¿µÃ¼ · Ì Ø¼
¼, where Ã¼ Ã · Ñ Ü ´ µ
¬
¬ ¾
Ì¼ Ì .
179

1. For all Ø Ø¼,
¬
¬
¬ at integral ÈØ Ê Ø
Ø¼
´ µ
¬
¬
¬
½ · ¾ where
ÈØ Ø½ ¡¡¡ ØÒ
Ñ Ñ Ò ¾ÆÒ
¬
¬ Ø Ø¼
´Ø¼µ ¡´ØÑ Ø¼µ · ¦
Ò ½
Ñ ´Ø µ¡Ø
½
¬
¬ at integral ÈØ ¬
¬
¾
¬
¬
¬ Ê Ø
Ø¼
´ µ
¬
¬
¬
Since ´ÈØµ ´Øµ
¬
¬Ì
Ø¼
Ë, there is Æ½ ¾´¼ µ such that Ø ¾ ¼ Ì Ë and
¬
¬ÈØ
¬
¬
Ø¼
Æ½ imply
¬
¬ ´ÈØµ ´Øµ
¬
¬ .
Therefore, when Ø ¾ Ø¼ Ì and
¬
¬ÈØ
¬
¬
Ø¼
Æ½, letting Å ¾ Ñ Ò ½
¬
¬ Ø ¾ Ë ,
180

we have
½
¬
¬
¬¦
Ò ½
½ Ú ¡Ø
¬
¬
¬ where Ú Ø½ ¡¡¡ Ø
(operational semantics of integral)
¬
¬
¬¦
Ñ ½
½ Ú ¡Ø · ¦
Ò ½
ÑÚ ¡Ø ´Ø¼µ ¡´ØÑ Ø¼µ ¦
Ò ½
Ñ ´Ø µ¡Ø
¬
¬
¬
¬
¬
¬¦
Ñ ½
½ Ú ¡Ø ´Ø¼µ ¡´ØÑ Ø¼µ · ¦
Ò ½
ÑÚ ¡Ø ¦
Ò ½
Ñ ´Ø µ¡Ø
¬
¬
¬
¬
¬
¬¦
Ñ ½
½ Ú ¡Ø
¬
¬
¬ · ´Ø¼µ ¡´ØÑ Ø¼µ · ¦
Ò ½
Ñ Ú ´Ø µ ¡Ø
Ã¼ ¡´ØÑ Ø½µ · Ã¼ ¡´ØÑ Ø¼µ · ¦
Ò ½
Ñ Ú ´Ø µ ¡Ø
Ã¼ ¡´´ØÑ Ø¼µ · ´Ø¼ Ø½µ · ´ØÑ Ø¼µµ · ¦
Ò ½
Ñ Ú ´Ø µ ¡Ø
¿Ã¼Æ½ · ¦
Ò ½
Ñ Ú ´Ø µ ¡Ø
´
¬
¬ÈØ
¬
¬
Ø¼
Æ½µ
¿Ã¼Æ½ · ¦ ¾ Ñ Ò ½ Å Ú ´Ø µ ¡Ø · ¦ ¾Å Ú ´Ø µ ¡Ø
¿Ã¼Æ½ · ¦ ¾ Ñ Ò ½ Å´¡Ø µ · ¦ ¾Å Ú ´Ø µ ¡Ø
¿Ã¼Æ½ · ´Ì Ø¼µ · ¦ ¾Å Ú ´Ø µ ¡Ø
¿Ã¼Æ½ · ´Ì Ø¼µ · ¦ ¾ÅÃ¼¡Ø
¿Ã¼Æ½ · ´Ì Ø¼µ · Ã¼ ¡ ¡´¾ · Æ½µ
´
¬
¬ÈØ
¬
¬
Ø¼
Æ½ and by the deﬁnition of Åµ
¿Ã¼ · ´Ì Ø¼µ · ¿ Ã¼
´Æ½ µ
´´¿ · ¿µÃ¼ · Ì Ø¼µ
¯ ¾
By Lemma A.3, we know there is Æ¾ ¼ (depending only on ¯), such that for all
Ø ¾ Ø¼ Ì and any non-empty non-descending sequence É Ø¼ ¡¡¡ Ø ,
É Æ¾ µ
¬
¬
¬
¬
¦
Ò ½
½ ´ µ¡
Ø
Ø¼
´ µ
¬
¬
¬
¬
¯ ¾
where É ½ ¡¡¡ Ò .
181

Since
¬
¬ÈØ
¬
¬
Ø¼
Æ¾ µ Ø¼ ØÑ ØÑ·½ ¡¡¡ ØÒ Æ¾, we have that
¾ ¯ ¾
Let Æ Ñ Ò Æ½ Æ¾ . We have that for all Ø ¾ Ø¼ Ì , and any non-empty non-
descending sequence È Ø,
¬
¬ÈØ¬
¬
Ø¼
Æ µ
¬
¬
¬
¬
at integral ÈØ
Ø
Ø¼
´ µ
¬
¬
¬
¬ ½ · ¾ ¯
2. When Ø Ø¼, for ÈØ where
¬
¬ÈØ
¬
¬
Ø¼
Æ, we have
¬
¬
¬ Ì Øintegral ÈØ Ê Ø
Ø¼
´ µ
¬
¬
¬
¬
¬
¬Ì Øintegral ÈØ ·
Ê Ø
Ø¼
´ µ
¬
¬
¬
¬
¬Ì Øintegral ÈØ
¬
¬ ·
¬
¬
¬
Ê Ø
Ø¼
´ µ
¬
¬
¬
´Ø Ø½µÃ¼ · ´Ø¼ ØµÃ¼
´Ø¼ Ø½µÃ¼
Ã¼Æ
Ã¼Æ½
Ã¼
¯
Since ¯ is arbitrary, we have proved that at integral ÈØ Ê Ø
Ø¼
´ µ
¬
¬
¬
Ì
Ø¼
.
Theorem 4.6 (Let-behavior). Given let behavior Þ ´Ü µ Û in ¼, we have that
and at ¼
Þ Ü Û ÈØ ´Øµ
¬
¬
¬
Ì
Ø¼
Ë
imply that
at ¼ ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë
182

Proof. By the operational semantics for let-behavior, we know that
at ÈØ at ¼
Þ Ü Û ÈØ
and we are done.
Theorem 4.7 (Until). Given ¼ until Ú µÞ ¾ÆÒ , and ,
1. if ¾ÆÒ occ
£ Ú Ø¼ Ì Nothing and at ¼ ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë, then
at ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë
2. if Ì¼ ¾´Ø¼ Ì ¾ÆÒ, such that
(a) occ£ Ú Ø¼ Ì¼ Just ´ Úµ,
(b) ¾ÆÒ occ
£ Ú Ø¼ Ì¼ Nothing,
(c) at ¼ ÈØ ´Øµ
¬
¬
Ø¼
Ë,
(d) at Û Ü Ù ÈØ ´Ù Øµ
¬
¬
Ì
Ë¼, where Ü Û ´Þ µ, and
(e) ¯ ¼ Æ ¼ Ø ¾ Ì Ù Ú Æ µ ´Ù Øµ ´Ú Øµ ¯,
then
at ÈØ ´Øµ
¬
¬
Ì
´Ë Ë¼ µ
where ´Øµ if Ø then ´Øµ else ´Ú Øµ.
Proof. Let at , ¼ at ¼ , and occ Ú .
1. The ﬁrst part of the theorem is proved as follows:
Since occ
£ Ú Ø¼ Ì Nothing, we know that given ¯ ¼, for all ¾ ÆÒ, there is
Æ ¼ such that
Ø ¾ Ø¼ Ì
¬
¬ÈØ¬
¬
Ø¼
Æ µ ´ÈØµ Nothing
183

(by the deﬁnition of occ and occ£ ).
By the operational semantics of until, for all Ø ¾ ¼ Ì and ÈØ where
¬
¬ÈØ
¬
¬
Ø¼
Æ (we
deﬁne Æ as Ñ Ò Æ ¾ÆÒ ), we have
´ÈØµ
¼´ÈØµ
And we are done.
2. Next we prove the second part of the theorem.
Given any ¯ ¼, for all Ø ¾ ¼ Ì Ë Ë¼
¯, there are two possibilities:
(a) Ø ¾ ¼ Ë Ë¼
¯.
There is Æ½ ¼, such that for all ÈØ where
¬
¬ÈØ
¬
¬
Ø¼
Æ½, we have
¾ÆÒ ´ÈØµ Nothing
Since ¼´ÈØµ ´Øµ
¬
¬
Ø¼
Ë, we can choose a Æ½ which makes
¬
¬ ¼´ÈØµ ´Øµ
¬
¬
¯.
By the operational semantics of until, we know that
¬
¬ ´ÈØµ ´Øµ
¬
¬
¬
¬
¬
¬
¬
¬ ¯
(b) Otherwise Ø ¾ Ì Ë Ë¼
¯.
Since ¯ ¼ Æ ¼ Ø ¾ Ì Ù Ú Æ µ ´Ù Øµ ´Ú Øµ ¯, we
know there is ¼ (depending only on ¯) such that
Ù Ú µ ´Ù Øµ ´Ú Øµ ¯ ¾
Since at Û Ü Ù ÈØ ´Ù Øµ
¬
¬
Ì
Ë¼, we know that there is Æ¾ ¼ (depend-
184

ing only on ¯), such that
¬
¬ÉØ¬
¬ Æ¾ µ ¬
¬ ´Ù ÉØµ ´Ù Øµ
¬
¬ ¯ ¾
where ´Ù ÉØµ
def
at Û Ü Ù ÉØ.
Now, we pick an arbitrary ¯¿ ¾ ´¼ Ñ Ò Æ¾ ¾ µ. By the deﬁnition of occ£ ,
we know that there is Æ¿ ¾´¼ Æ¾ ¾µ (depending only on ¯¿), ¼, and Ù such that
¬
¬ÈØ¬
¬
Ø¼
Æ¿ µ ´ÈØµ Just ´
¼ Ùµ and ¾ÆÒ ´Êµ Nothing
where ¼ ¯¿ and Ù Ú ¯¿, and Ê Ø½ ¡¡¡ ØÑ·½ where ÈØ
Ø½ ¡¡¡ ØÑ
¼ ØÑ·½ ¡¡¡ ØÒ .
let ÉØ ØÑ·½ ¡¡¡ ØÒ where ÈØ Ø½ ¡¡¡ ØÑ
¼ ØÑ·½ ¡¡¡ ØÒ .
By the operational semantics of until, we have that
´ÈØµ ´Ù ÉØµ
Since
¬
¬ÉØ
¬
¬ Æ¿ · ¯¿ Æ¾ ¾ · Æ¾ ¾ Æ¾, we know that
¬
¬
¬ ¯ ¾
Therefore,
¬
¬ ´ÈØµ ´Øµ
¬
¬
¬
¬ ´ÈØµ ´Ú Øµ
¬
¬
¬
¬ ´Ù ÉØµ ´Ú Øµ
¬
¬
¬
¬ ´Ù ÉØµ ´Ù Øµ · ´Ù Øµ ´Ú Øµ
¬
¬
¬
¬
¬ · ´Ù Øµ ´Ú Øµ
¯ ¾ · ¯ ¾
¯
185

Combining the above two cases, we know that for any given ¯ ¼, there is Æ
Ñ Ò Æ½ Æ¿ ¼, such that for all Ø ¾ Ø¼ Ì Ë Ë¼
¯ and ÈØ where
¬
¬ÈØ
¬
¬
Ø¼
Æ,
we have
¬
¬ ´ÈØµ ´Øµ
¬
¬ ¯. And we are done.
Theorem 4.8 (When). Given Ú when and Ú , we have
1. if at ÈØ ´Øµ
¬
¬
Ì
Ø¼
, and there are Ì¼ Ì½ where Ì¼ Ð Ø¼ Ì½ Ì, such that
(a) Ì¼ Ø Ì½ µ ´Øµ True, and
(b) Ì½ Ø Ì µ ´Øµ False,
then occ
£ Ú Ø¼ Ì Nothing;
2. if there are Ì¼ Ì½ Ì¾ Ì¿ ¾Ì where Ì¼ Ð Ø¼ Ì½ Ì¾ Ì¿ Ì, such that
(a) at ÈØ ´Øµ
¬
¬
Ì¿
Ø¼
,
(b) Ø ¾ Ì¼ Ì½µ ´Ì¾ Ì¿ µ ´Øµ True, and
(c) Ø ¾´Ì½ Ì¾µ µ ´Øµ False,
then occ
£ Ú Ø¼ Ì Just ´Ì¾ ´µµ.
Proof. 1. First we prove part 1 of the theorem. We can ﬁnd a Æ ¼ such that for
all Ø ¾ ¼ Ì and ÈØ where
¬
¬ÈØ
¬
¬
Ø¼
Æ, we have
¬
¬ at ÈØ ´Øµ
¬
¬ ¼ . Since
is a Boolean behavior, whose only two possible values are True and False, where
True False ½, this practically means that at ÈØ ´Øµ.
Let ÈÌ be a time sequence where
¬
¬ÈÌ
¬
¬
Ø¼
Æ. Assume ÈÌ Ø½ ¡¡¡ ØÒ and
trace ÈÌ Ú½ ¡¡¡ ÚÒ . We have that there is ¾ÆÒ ½ where Ú True,
and ¾ · ½ Ò ½ Ú False. Thus, by the deﬁnition of occ , we know
occ Ú ÈÌ Nothing. Since ÈÌ is arbitrary, we have that occ£ Ú Ø¼ Ì
Nothing.
186

2. The proof for the second part is similar. Given an ¯ ¼, we can choose a Æ ¼ such
that
(a) Æ
Ñ Ò ¯ Ì¾ Ì½ Ì¿ Ì¾
¾
,
(b) if Ø¼ Ì¼, then Æ Ø¼ Ì¼, and
(c) for all Ø ¾ ¼ Ì¿ and ÈØ where
¬
¬ÈØ
¬
¬
Ø¼
Æ, we have at ÈØ ´Øµ.
Let ÈÌ be a time sequence where
¬
¬ÈÌ
¬
¬
Ø¼
Æ. Assume ÈÌ Ø½ ¡¡¡ ØÒ and
trace ÈÌ Ú½ ¡¡¡ ÚÒ . It is obvious that ¾ÆÒ Ú ´Ø µ.
We proceed by comparing the ﬁrst element in È Ì (i.e. Ø½) with Ì½:
(a) if Ø½ Ì½, then for all ¾ÆÒ Ø ¾ Ì¼ Ì½µ;
(b) otherwise Ø½ Ì½. Since Ì¼ Ð Ø¼, there are in turn two possibilities:
i. Ì¼ Ø¼ ¼. We know that Ø½ Ì¼, since Ø½ ¾Ì.
ii. Ì¼ Ø¼. Since Ø½ Ø¼ Æ and Æ Ø¼ Ì¼, we also know that Ø½ Ì¼.
In either case, there is Ñ ¾ÆÒ ¾ÆÑ ´µØ ¾ Ì¼ Ì½µ.
Therefore, no matter Ø½ is less than Ì½ or not, there is Ñ ¾ ¼ Ò such that ¾
ÆÒ ¾ÆÑ ´µØ ¾ Ì¼ Ì½µ.
Since
¬
¬ÈÌ
¬
¬
Ø¼
Æ, Æ
Ì¾ Ì½
¾
, and Æ
Ì¿ Ì¾
¾
. we know that there is ¾ Ñ· ¾ Ò
such that ØÑ·¾ ØÑ·¿ ¡¡¡ Ø ¾´Ì½ Ì¾µ and Ø ·¾ ¾´Ì¾ Ì¿ .
Since ¾ÆÒ Ú ´Ø µ, we now have that
(a) for all Ñ, Ú True,
(b) ÚÑ·¾ ÚÑ·¿ ¡¡¡ Ú False, where Ñ · ¾, and
(c) Ú ·¾ True.
Let ¼ · ½ (if Ú ·½ True) or · ¾ (otherwise). By the operational semantics of
when, we have occ Ú ÈÌ Just ´Ø ¼ ´µµ.
187

Since Ø ¼ Ì¾ ¾Æ ¯, and ¯ is arbitrary, we know that occ£ Ú Ø¼ Ì Just ´Ì¾ ´µµ.
Now we have proved both parts of the theorem, and we are done.
Theorem 4.9 (Liftev). Given Ú liftev ´ ´Ü¼ ¡¡¡ ÜÒµ µ Ú¼ ½ ¡¡¡ Ò and where
Ú , write Ó for occ
£ Ú Ø¼ Ì and Ó ¼ for occ
£ Ú¼ Ø¼ Ì. We have
1. Ó ¼ Nothing µ Ó Nothing, and
2. if
(a) Ó ¼ Just ´ Ú¼µ,
(b) there is ¼ such that for all ¾ÆÒ,
i. at ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë where ¾ Ë , and
ii. ´Øµ is continuous at Ø ,
and
(c) the function ´Ý¼ Ý½ ¡¡¡ ÝÒµ eval Ü Ý ¾ ¼ Ò is continuous at
´Ú¼ Ú½ ¡¡¡ ÚÒµ, where ¾ÆÒ Ú ´ µ,
then Ó Just ´ ´Ú¼ Ú½ ¡¡¡ ÚÒµµ.
Proof. 1. By the operational semantics of liftev, occ Ú¼ ÈÌ Nothing µ occ Ú ÈÌ
Nothing. Since Ó ¼ Ð Ñ ÈÌ
Ø¼
¼ occ Ú¼ ÈÌ , and Ó Ð Ñ ÈÌ
Ø¼
¼ occ Ú ÈÌ , we
know that Ó ¼ Nothing µ Ó Nothing
2. Given any ¯ ¼, since is continuous at ´Ú¼ Ú½ ¡¡¡ ÚÒµ, there is ½ ¼ such that
´Ú¼
¼ Ú¼
½ ¡¡¡ Ú¼
Òµ ´Ú¼ Ú½ ¡¡¡ ÚÒµ ½ µ
´Ú¼
¼ Ú¼
½ ¡¡¡ Ú¼
Òµ ´Ú¼ Ú½ ¡¡¡ ÚÒµ ¯ ¾
Since ¾ ÆÒ ´Øµ is continuous at Ø , there is ¾ ¼ such that ¼
¾ µ ¾ÆÒ
¬
¬
¬ Ú¼ Ú
¬
¬
¬
½
¾Ò · ½
where Ú¼ ´
¼µ.
188

Let ¿ Ñ Ò ¯ ¾ ¾
½
¾Ò · ½
¾ . Since Ó ¼ Just ´ Ú¼µ, there is Æ½ ¼ (depending
only on ¿) such that
¬
¬ÈÌ
¬
¬
Ø¼
Æ½ µ occ Ú¼ ÈÌ Just ´
¼ Ú¼
¼µ where ¼
¿ and Ú¼
¼ Ú¼ ¿.
Since ¼ ¿, ¾ Ë , and ¿ ·¿ , we know that ¼ ¾ Ë ¿
for all ¾ÆÒ.
Since at ÈØ ´Øµ
¬
¬
Ì
Ø¼
Ë and ¼ ¾ Ë ¿
, there is Æ¾ ¼ (depending only on
¿) such that
¬
¬
¬È
¼¬
¬
¬
Ø¼
Æ¾ implies
¬
¬
¬ at È
¼
´
¼µ
¬
¬
¬ ¿.
Therefore, for any ÈÌ where
¬
¬ÈÌ
¬
¬
Ø¼
Æ Ñ Ò Æ½ Æ¾ , we have
¬
¬ occ Ú ÈÌ Just ´ ´Ú¼ Ú½ ¡¡¡ ÚÒµµ
¬
¬
Just ´
¼ ´Ú¼
¼ Ù½ ¡¡¡ ÙÒµµ Just ´ ´Ú¼ Ú½ ¡¡¡ ÚÒµµ
where Just ´
¼ Ú¼
¼µ occ Ú¼ ÈÌ Ù at É
¼
, and
É
¼
is the preﬁx of ÈÌ ending at ¼
(by the operational semantics of liftev)
¼ · ´Ú¼
¼ Ù½ ¡¡¡ ÙÒµ ´Ú¼ Ú½ ¡¡¡ ÚÒµ
Since
¬
¬ÈÌ
¬
¬
Ø¼
Æ Æ½, we know ¼ ¿ and Ú¼
¼ Ú¼ ¿.
Since
¬
¬ÈÌ
¬
¬
Ø¼
Æ Æ¾, we know ¾ÆÒ
¬
¬
¬ Ù Ú¼
¬
¬
¬ ¿.
Since ¼ ¿ ¾, we also know that ¾ÆÒ
¬
¬
¬ Ú¼ Ú
¬
¬
¬
½
¾Ò · ½
.
189

Hence,
´Ú¼
¼ Ù½ ¡¡¡ ÙÒµ ´Ú¼ Ú½ ¡¡¡ ÚÒµ
Ú¼
¼ Ú¼ · ¦
Ò
½ Ù Ú
¿ · ¦
Ò
½ Ù Ú
¿ · ¦
Ò
½
¬
¬
¬Ù Ú¼ · Ú¼ Ú
¬
¬
¬
¿ · ¦
Ò
½
¬
¬
¬ Ù Ú¼
¬
¬
¬ ·
¬
¬
¬ Ú¼ Ú
¬
¬
¬
¿ · ¦
Ò
½
¼
¿ ·
½
¾Ò · ½
½
¿ · ¦
Ò
½
¼
½
¾Ò · ½
·
½
¾Ò · ½
½
¿ ·
¾Ò½
¾Ò · ½
½
¾Ò · ½
·
¾Ò½
¾Ò · ½
½
which in turn leads to
¬
¬ ´Ú¼
¼ Ú¼
½ ¡¡¡ Ú¼
Òµ ´Ú¼ Ú½ ¡¡¡ ÚÒµ
¬
¬ ¯ ¾
Therefore, now we have
¬
¬ occ Ú ÈÌ Just ´ ´Ú¼ Ú½ ¡¡¡ ÚÒµµ
¬
¬
¼ · ´Ú¼
¼ Ù½ ¡¡¡ ÙÒµ ´Ú¼ Ú½ ¡¡¡ ÚÒµ
¿ · ¯ ¾
¯ ¾ · ¯ ¾
¯
Since ¯ is arbitrary, we have proved that Ó Just ´ ´Ú¼ Ú½ ¡¡¡ ÚÒµµ.
190

Lemma 5.1 (Deterministic semantics). If the base language is deterministic, then we
have that
´È Á
È and È Á ¼ È¼µ µ ´
¼ and È È¼µ
Proof. We prove the lemma in two steps.
1. First, we prove that È
Á
¶ Ú and È
Á
¶ Ú¼ imply that Ú Ú¼.
The proof is by induction on the derivation trees for È
Á
¶ Ú. Let’s call this
derivation ½ and that for and È
Á
¶ Ú¼ ¾. There are three cases:
(a) The last rule used in ½ is e1. The term must have the form (a base language
term). Hence the last rule in ¾ must also be e1. By induction hypothesis and
the deterministic semantics of the base language, we have that Ú Ú¼.
(b) The last rule used in ½ is e2. By similar reasoning as above, the last rule in
¾ must be e2 too. Then we get by the deterministic semantics of the base
language that Ú Ú¼.
(c) The last rule in ½ is e3. In this case, the last rule in ¾ must also be e3. It then
follows trivially that Ú Ú¼.
2. Next, we prove that È Á
· ¼ and È Á
· ¼¼ imply that ¼ ¼¼.
Let ½ be the derivation tree for È
Á
· ¼, and ¾ be that for È
Á
· ¼¼. The
proof is by induction on ½.
(a) The last rule used in ½ is u1. We have ¼ and ¼¼. Therefore,
¼ ¼¼.
(b) The last rule in ½ is u2. The last rule in ¾ has to be u2 too. By part one of the
proof, we know that ¼ ¼¼.
(c) The last rule in ½ is u3. We have ¼ and ¼¼. Hence ¼ ¼¼.
191

Combining part 1 and 2, by rule p, we know that
È
Á
È È
Á ¼ È¼ µ ¼ È È¼
Theorem 5.1 (Source-target correspondence). Given that È, È É, and È Á
È¼,
we have
1. È¼ É; and
2. if É ×Ø Ø ´Èµ
Á
¸ ¼ ¼¼, then ¼ and ¼¼ ×Ø Ø ´È¼µ.
In the proof that follows, we use the notation
for the environment obtained from restricting to variables in , i.e.
Ü ´Üµ
¬
¬ Ü ¾
Proof. Based on the form of the behavior deﬁnitions, we can divide the source program È
into four disjoint sets:
È Ü ¾Â
Ü init Ý Ú in Á µ À ¾Ã
Ü init Ý Ú in Á µ later À ¾Ä
Ü init Ý Ú in À ¾Å
where Â, Ã, Ä, and Å are disjoint sets of natural numbers, and for all ¾Å, À does not
contain Á.
By the deﬁnition of È É, we know that for any Á ¾ Á, there are and ¼ such that
192

È ½
Á and È ¾
Á
¼. The core of the proof is by induction on the derivation of È ½
Á
and È ¾
Á
¼.
Part 1: By inspecting the operational semantics of E-FRP, we know that
È¼ Ü ¾Â
Ü init Ý Ú¼ in Á µ À ¾Ã
Ü init Ý Ú¼ in Á µ later À ¾Ä
Ü init Ý Ú in À ¾Å
for some Ú¼ ¾Ã Ä.
Given this, we can easily verify that È¼ ½
Á and È¼ ¾
Á
¼, and therefore È¼ É.
Part 2: From now on, we let ¼ ×Ø Ø ´Èµ, ½ ×Ø Ø ´È¼µ, Æ Â Ã Ä Å, and
Ò the size of Æ. We want to prove the following proposition:
Proposition 1. For any ¾Æ,
1. ¼´Ü µ ´Ü µ;
2. if ¾Ä, then ¼´Ü·
µ ½´Ü µ; and
3. if ¾Å, then ¼´Ü·
µ
¼´Ü µ.
Since Proposition 1 is establishing a property of , for brevity we give this property a
name Ô and write Ô´ µ for that has this property. Hence Proposition 1 can be expressed
as “ ¾ Æ Ô´ µ.” To show that this is true, we note that the derivation of È ½
Á has the
form:
ÈÒ
½
Á Ò side-conditionÒ
ÈÒ ½
½
Á Ò ½ side-conditionÒ ½
...
È¼
½
Á ¼
where ÈÒ , Ò , È¼ È, ¼ , and for all ¾ÆÒ, È ½ Ü ¡¡¡ È ½. It
is clear that assigns to any variable at most once.
193

Apparently, ½ ¡¡¡ Ò is a permutation of Æ. Therefore we can prove Proposition 1
by showing that the following equivalent proposition is true:
Proposition 2. For any ¾ÆÒ, we have Ô´ µ.
The proof for Proposition 2 is by induction on . Given ¾ ÆÒ, assuming that ¾
Æ ½ Ô´ µ, we try to prove that Ô´ µ:
Let . There are four cases:
1. ¾ Â. We know that ´Ü µ ¾ È, and that the rule leading to È ½
½
Á ½ is x2.
Hence ½ Ü ·· and Ü .
Since Ü , we have that for all Ü ¾ Î ´ µ, it has to be in one of the two
following cases:
(a) Ü ¾ Ü ¾Æ ½ . By the induction hypothesis, ¼´Üµ ´Üµ.
(b) Ü Ü for some . Let Ð . This again can be divided into two cases:
i. ´ÜÐ init ÝÐ ÚÐ in Á µ Ð later ÀÐµ ¾È. In this case, ¼´Üµ ¼´Üµ
ÚÐ ´Üµ.
ii. ´ÜÐ init ÝÐ ÚÐ in ÀÐµ ¾È, where Á does not occur in ÀÐ. In this case, we
also have ¼´Üµ ¼´Üµ ÚÐ ´Üµ.
Therefore we have ¼´Üµ ´Üµ for all Ü ¾ Î ´ µ.
By rule c2, we have ¼´Ü µ Ú¼ where ¸ Ú¼ where ´Üµ
¼´Üµ ´Üµ
for all Ü ¾ Î ´ µ. By rule e1, we know that ´Ü µ Ú where Î ´ µ ¸ Ú.
Finally, by Lemma 2.3 we have that Ú Ú¼, and therefore ¼´Ü µ ´Ü µ.
2. ¾ Ã. We know that ´Ü init Ý Ú in Á µ À µ ¾ È and the rule leading
to È ½
½
Á ½ is x3. Hence ½ Ü ·· and Ü , where
Ý Ü·
. Since Ü , we know that for all Ü ¾ Î ´ µ, it must fall into
one of the following three cases:
(a) Ü Ü·
. ¼´Üµ ¼´Ü·
µ Ú .
194

(b) Ü ¾ Ü ¾Æ ½ . By the induction hypothesis, ¼´Üµ ´Üµ.
(c) Ü Ü for some . Let Ð . By the same reasoning we used in bullet 1,
we have that ¼´Üµ ¼´Üµ ÚÐ ´Üµ.
By rule c2, we have that ¼´Ü µ Ú¼ where ¸ Ú¼ where ´Ü·
µ Ú and
´Üµ
¼´Üµ ´Üµ for all Ü ¾ Î ´ µ Ü·
. By rule e2, we know that ´Ü µ Ú
where Î ´ Ý Ú µ Ý Ú ¸ Ú. Thus by Lemma 2.8, we get that Ú¼ Ú
and therefore ¼´Ü µ ´Ü µ.
3. ¾ Ä. We know that ´Ü init Ý Ú in Á µ later À µ ¾ È and the rule
leading to È ½
½
Á ½ is x4. Hence ½ Ü·
·· and Ü·
,
where Ý Ü . Since does not assign to Ü , we have that ¼´Ü µ ¼´Ü µ
Ú ´Ü µ.
Since Ü·
, we have that for all Ü ¾ Î ´ µ, it has to be in one of the two
following cases:
(a) Ü ¾ Ü ¾Æ ½ . By the induction hypothesis, ¼´Üµ ´Üµ.
(b) Ü Ü for some . Let Ð . By the same reasoning we used in bullet 1,
we have that ¼´Üµ ¼´Üµ ÚÐ ´Üµ.
Therefore we have ¼´Üµ ´Üµ for all Ü ¾ Î ´ µ.
Since ½ Ü·
·· , we have that ¼´Ü·
µ Ú¼ where ¸ Ú¼ where
´Üµ
¼´Üµ ´Üµ for all Ü ¾ Î ´ µ.
Meanwhile, by rule u2 we have that ½´Ü µ Ú where Ý Ú ¸ Ú.
Hence, by Lemma 2.8 we get Ú¼ Ú, and thus ¼´Ü·
µ ½´Ü µ.
4. Otherwise ¾ Å. We know that ´Ü init Ý Ú in À µ ¾ È where Á does not
occur in À , and the rule leading to È ½
½
Á ½ is x5. Hence ½ , and
195

therefore does not assign to either Ü or Ü·
. Therefore we have
¼´Ü µ ¼´Ü µ Ú ´Ü µ
and
¼´Ü·
µ ¼´Ü·
µ Ú ¼´Ü µ
Putting the above cases together, we have proved Proposition 2.
Next, we want to prove:
Proposition 3. For any ¾Æ, has the property that
1. ¼¼´Ü µ ½´Ü µ; and
2. if ¾Ã Ä Å, then ¼¼´Ü·
µ ½´Ü µ.
We will call this property Õ.
Note that the derivation of È ¾
Á
¼ has the form:
ÈÒ
¾
Á Ò side-conditionÒ
ÈÒ ½
¾
Á Ò ½ side-conditionÒ ½
...
È¼
¾
Á ¼
where ÈÒ , Ò , È¼ È, ¼
¼, and for all ¾ÆÒ, È ½ Ü ¡¡¡ È ½. It
is clear that ¼ assigns to any variable at most once.
Apparently, ½ ¡¡¡ Ò is a permutation of Æ. Therefore we can show Proposition 1 is
true by proving the following proposition, which is equivalent to Proposition 3:
Proposition 4. For any ¾ÆÒ, we have Õ´ µ.
The proof is by induction on : given ¾ ÆÒ, assuming that ¾ Æ ½ Õ´ µ, we try
to prove that Õ´ µ:
196

Let . There are four cases:
1. ¾ Â. We know that ´Ü µ ¾ È, and that the rule leading to È ½
¾
Á ½ is x7.
Hence ½ Ü ·· and Ü .
Since Ü , we have that for all Ü ¾ Î ´ µ, it has to be in one of the two
following cases:
(a) Ü ¾ Ü ¾Æ ½ . By the induction hypothesis, ¼¼´Üµ ½´Üµ.
(b) Ü Ü for some . Let Ð . This again can be divided into two cases:
i. ´ÜÐ init ÝÐ ÚÐ in Á µ Ð ÀÐµ ¾ È. In this case, by Proposition 1 we
have ¼¼´Üµ
¼´Üµ ´Üµ ½´Üµ.
ii. ´ÜÐ init ÝÐ ÚÐ in ÀÐµ ¾È, where Á does not occur in ÀÐ. In this case, we
also have (by Proposition 1 again) that ¼¼´Üµ
¼´Üµ ´Üµ ½´Üµ.
Therefore we have ¼¼´Üµ ½´Üµ for all Ü ¾ Î ´ µ.
By rule c2, we know that ¼¼´Ü µ Ú¼ where ¸ Ú¼ where ´Üµ ½´Üµ for all
Ü ¾ Î ´ µ. Meanwhile, by rule u1 we have ½´Ü µ Ú where ½ Î ´ µ ¸ Ú.
Therefore, by Lemma 2.3 we have Ú¼ Ú¼, or ¼¼´Ü µ ½´Ü µ.
2. ¾ Ã. We know that ´Ü init Ý Ú in Á µ À µ ¾ È and the rule leading
to È ½
½
Á ½ is x8. Hence ½ Ü·
Ü ·· and ¼ does not assign to
Ü . Therefore by Proposition 1, we have ¼¼´Ü µ
¼´Ü µ ´Ü µ ½´Ü µ and
¼¼´Ü·
µ
¼´Ü µ ½´Ü µ.
3. ¾ Ä. We know that ´Ü init Ý Ú in Á µ later À µ ¾ È and the rule
leading to È ½
½
Á ½ is x9. Hence ½ Ü Ü·
·· and ¼ does not
assign to Ü·
. Therefore by Proposition 1, we have ¼¼´Ü µ
¼´Ü·
µ ½´Ü µ and
¼¼´Ü·
µ
¼´Ü·
µ ½´Ü µ.
4. ¾Å. We know that ´Ü init Ý Ú in À µ ¾È where Á does not occur in À , and
the rule leading to È ½
½
Á ½ is x10. Hence ½ , and therefore ¼ does
197

not assign to either Ü or Ü·
. Therefore by proposition 1 we have ¼¼´Ü µ
¼´Ü µ
´Ü µ Ú ½´Ü µ and ¼¼´Ü·
µ
¼´Ü·
µ
¼´Ü µ ´Ü µ Ú ½´Ü µ.
Putting the above cases together, we have proved Proposition 4.
Finally, from Proposition 1 and 2, we can derive part 2 of Theorem 5.1 trivially, and we
are done.
198

Bibliography
[1] Rajeev Alur, Costas Courcoubetis, Thomas A. Henzinger, and Pei-Hsin Ho. Hybrid
automata: An algorithmic approach to the specification and verification of hybrid
systems. In Hybrid Systems, pages 209–229, 1992.
[2] Rajeev Alur and David L. Dill. A theory of timed automata. Theoretical Computer
Science, 126(2):183–235, 1994.
[3] Tom M. Apostol. Mathematical Analysis — A Modern Approach to Advanced Calculus.
Addison-Wesley, 1957.
[4] Gérard Berry. The constructive semantics of pure esteral (draft version 3). Draft
Version 3, Ecole des Mines de Paris and INRIA, July 1999.
[5] Gérard Berry. The Esterel v5 Language Primer Version 5.21 release 2.0. Centre de
Mathématiques Appliquées, Ecole des Mines and INRIA, 2004 Route des Lucioles,
06565 Sophia-Antipolis, April 1999.
[6] Gerard Berry and Laurent Cosserat. The Esterel synchronous programming language
and its mathematical semantics. In A.W. Roscoe S.D. Brookes and editors G. Winskel,
editors, Seminar on Concurrency, volume 197 of Lect. Notes in Computer Science, pages
389–448. Springer Verlag, 1985.
[7] Paul Caspi, Halbwachs Halbwachs, Nicolas Pilaud, and John A. Plaice. Lustre: A
declarative language for programming synchronous systems. In the Symposium on
Principles of Programming Languages (POPL ’87), January 1987.
199

[8] Paul Caspi and Marc Pouzet. Synchronous Kahn networks. ACM SIGPLAN Notices,
31(6):226–238, 1996.
[9] Richard Courant and Fritz John. Introduction to Calculus and Analysis, volume 1. In-
terscience Publishers, 1965.
[10] Antony Courtney. Frappé: Functional reactive programming in Java. In Proceedings
of Symposium on Practical Aspects of Declarative Languages. ACM, 2001.
[11] Antony Courtney and Conal Elliott. Genuinely functional user interfaces. In Haskell
Workshop, 2001.
[12] Anthony C. Daniels. A Semantics for Functions and Behaviours. PhD thesis, The Uni-
versity of Nottingham, December 1999.
[13] Abbas Edalat and Peter John Potts. A new representation for exact real numbers.
Electronical Notes in Theoretical Computer Science, 6:14 pp., 1997. Mathematical foun-
dations of programming semantics (Pittsburgh, PA, 1997).
[14] Conal Elliott. Modeling interactive 3D and multimedia animation with an embedded
language. In Proceedings of the first conference on Domain-Specific Languages, pages 285–
296. USENIX, October 1997.
[15] Conal Elliott. Functional implementations of continuous modeled animation. In
Proceedings of PLILP/ALP ’98. Springer-Verlag, 1998.
[16] Conal Elliott and Paul Hudak. Functional reactive animation. In International Confer-
ence on Functional Programming, pages 163–173, Amsterdam, June 1997.
[17] John Peterson et al. Haskell 1.4: A non-strict, purely functional lan-
guage. Technical Report YALEU/DCS/RR-1106, Department of Com-
puter Science, Yale University, Mar 1997. World Wide Web version at
http://haskell.cs.yale.edu/haskell-report.
200

[18] Thierry Gautier, Paul Le Guernic, and Loic Besnard. Signal: A declarative language
for synchronous programming of real-time systems. In Gilles Kahn, editor, Func-
tional Programming Languages and Computer Architecture, volume 274 of Lect Notes in
Computer Science, edited by G. Goos and J. Hartmanis, pages 257–277. Springer-Verlag,
1987.
[19] K. Hammond. Parallel functional programming: An introduction. In International
Symposium on Parallel Symbolic Computation. World Scientific, 1994.
[20] Constance Heitmeyer. Applying Practical formal methods to the specification and
analysis of security properties. In Proc. Information Assurance in Computer Networks,
LNCS 2052, St. Petersburg, Russia, May 2001. Springer-Verlag.
[21] Constance Heitmeyer, James Kirby, Bruce Labaw, and Ramesh Bharadwaj. SCR*: A
toolset for specifying and analyzing software requirements. In Proc. Computer-Aided
Verification, Vancouver, Canada, 1998.
[22] Thomas A. Henzinger. The theory of hybrid automata. Technical report, University
of California, Berkeley, 1996.
[23] Martin Hofmann. A type system for bounded space and functional in-place update.
In European Symposium on Programming (ESOP), Lecture Notes in Computer Science.
Springer-Verlag, 2000.
[24] Paul Hudak. Modular domain specific languages and tools. In Proceedings of Fifth In-
ternational Conference on Software Reuse, pages 134–142. IEEE Computer Society, June
1998.
[25] Paul Hudak. The Haskell School of Expression – Learning Functional Programming
through Multimedia. Cambridge University Press, New York, 2000.
201

[26] Paul Hudak, Simon Peyton Jones, and Philip Wadler (editors). Report on the Pro-
gramming Language Haskell, A Non-strict Purely Functional Language (Version
1.2). ACM SIGPLAN Notices, 27(5), May 1992.
[27] John Hughes. Generalising monads to arrows. Science of Computer Programming,
37:67–111, May 2000.
[28] John Hughes and Lars Pareto. Recursion and dynamic data-structures in bounded
space: Towards embedded ML programming. In Proceedings of the Fourth ACM SIG-
PLAN International Conference on Functional Programming (ICFP-99), volume 34.9 of
ACM Sigplan Notices, pages 70–81, N.Y., September 27–29 1999. ACM Press.
[29] John Hughes, Lars Pareto, and Amr Sabry. Proving the correctness of reactive sys-
tems using sized types. In Guy L. Steele Jr, editor, Principles of Programming Languages,
volume 23, St Petersburg, Florida, 1996. ACM Press.
[30] Richard Kieburtz. Real-time reactive programming for embedded controllers. Avail-
able from author’s home page, March 2001.
[31] Richard B. Kieburtz. Implementing closed domain-speciﬁc languages. In [49], pages
1–2, 2000.
[32] O. (Oded) Maler, editor. Hybrid and real-time systems: international workshop, HART
’97, Grenoble, France, March 26–28, 1997: proceedings, volume 1201 of Lecture Notes in
Computer Science, New York, NY, USA, 1997. Springer-Verlag.
[33] Microchip Technology Inc. PIC16C66 Datasheet. Available on-line at
http://www.microchip.com/.
[34] Eugenio Moggi, Walid Taha, Zine El-Abidine Benaissa, and Tim Sheard. An ideal-
ized MetaML: Simpler, and more expressive. In European Symposium on Programming
(ESOP), volume 1576 of Lecture Notes in Computer Science, pages 193–207. Springer-
Verlag, 1999.
202

[35] Edwin E. Moise. Calculus. Addison-Wesley, 1967.
[36] Andrzej S. Murawski and C.-H. L. Ong. Can safe recursion be interpreted in light
logic? In Second International Workshop on Implicit Computational Complexity, Santa
Barbara, June 200.
[37] Alan Mycroft and Richard Sharp. A statically allocated parallel functional language.
In Automata, Languages and Programming, pages 37–48, 2000.
[38] Henrik Nilsson, Antony Courtney, and John Peterson. Functional Reactive Program-
ming, continued. In ACM SIGPLAN 2002 Haskell Workshop, October 2002.
[39] Online documentation for the ICE programming language.
http://www.cognitoy.com/twiki/.
[40] Ross Paterson. A new notation for arrows. In International Conference on Functional
Programming, pages 229–240. ACM Press, September 2001.
[41] Izzet Pembeci, Henrik Nilsson, and Greogory Hager. Functional reactive robotics:
An exercise in principled integration of domain-specific languages. In Principles and
Practice of Declarative Programming (PPDP’02), October 2002.
[42] John Peterson, Gregory Hager, and Paul Hudak. A language for declarative robotic
programming. In Proceedings of IEEE Conference on Robotics and Automation, 1999.
[43] Jonathan Rees and William Clinger (eds.). Revised¿ report on the algorithmic lan-
guage Scheme. SIGPLAN Notices, 21(12):37–79, December 1986.
[44] Alastair Reid, John Peterson, Greg Hager, and Paul Hudak. Prototyping real-time vi-
sion systems: An experiment in DSL design. In Proceedings of International Conference
on Software Engineering, May 1999.
[45] MindRover official web-site. http://www.mindrover.com/.
[46] RoboCup official web-site. http://www.robocup.org/.
203

[47] Christopher Strachey. The varieties of programming language. Technical Report
Technical monograph PRG-10, Programming research group, Oxford University
computing laboratory, 1973.
[48] Walid Taha. Multi-Stage Programming: Its Theory and Applications. PhD the-
sis, Oregon Graduate Institute of Science and Technology, 1999. Available from
ftp://cse.ogi.edu/pub/tech-reports/README.html.
[49] Walid Taha, editor. Semantics, Applications, and Implementation of Program Generation,
volume 1924 of Lecture Notes in Computer Science, Montréal, 2000. Springer-Verlag.
[50] Walid Taha, Zine-El-Abidine Benaissa, and Tim Sheard. Multi-stage programming:
Axiomatization and type-safety. In 25th International Colloquium on Automata, Lan-
guages, and Programming (ICALP), volume 1443 of Lecture Notes in Computer Science,
pages 918–929, Aalborg, 1998.
[51] J. E. Vuillemin. Exact real computer arithmetic with continued fractions. IEEE Trans-
actions on Computers, 39(8):1087–1105, 1990.
[52] William W. Wadge and Edward A. Ashcroft. Lucid, the Dataflow Programming Lan-
guage. Academic Press U.K., London, 1985.
[53] Zhanyong Wan and Paul Hudak. Functional reactive programming from first prin-
ciples. In Proceedings of the ACM SIGPLAN ’00 Conference on Programming Language
Design and Implementation (PLDI), pages 242–252, Vancouver, BC, Canada, June 2000.
ACM, ACM Press.
[54] Zhanyong Wan, Walid Taha, and Paul Hudak. Real-time FRP. In Proceedings of Sixth
ACM SIGPLAN International Conference on Functional Programming, Florence, Italy,
September 2001. ACM.
204

[55] Zhanyong Wan, Walid Taha, and Paul Hudak. Event-driven FRP. In Proceedings of
Fourth International Symposium on Practical Aspects of Declarative Languages. ACM, Jan
2002.
205

Modelling Time in Computation (Dynamic Systems)

More Related Content

What's hot (18)

Similar to Modelling Time in Computation (Dynamic Systems) (20)

More from M Reza Rahmati (20)

Recently uploaded (20)

Modelling Time in Computation (Dynamic Systems)