Functional reactive programming library

root / README.md

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
Netwire
=======

Netwire is a functional reactive programming (FRP) library with signal
inhibition.  It implements three related concepts, *wires*, *intervals*
and *events*, the most important of which is the *wire*.  To work with
wires we will need a few imports:

    import FRP.Netwire
    import Prelude hiding ((.), id)

The `FRP.Netwire` module exports the basic types and helper functions.
It also has some convenience reexports you will pretty much always need
when working with wires, including `Control.Category`.  This is why we
need the explicit `Prelude` import.

In general wires are generalized automaton arrows, so you can express
many design patterns using them.  The `FRP.Netwire` module provides a
proper FRP framework based on them, which strictly respects continuous
time and discrete event semantics.  When developing a framework based on
Netwire, e.g. a GUI library or a game engine, you may want to import
`Control.Wire` instead.


Introduction
------------

The following type is central to the entire library:

    data Wire s e m a b

Don't worry about the large number of type arguments.  They all have
very simple meanings, which will be explained below.

A value of this type is called a *wire* and represents a *reactive*
value of type $b$, that is a value that may change over time.  It may
depend on a reactive value of type $a$.  In a sense a wire is a function
from a reactive value of type $a$ to a reactive value of type $b$, so
whenever you see something of type `Wire s e m a b` your mind should
draw an arrow from $a$ to $b$.  In FRP terminology a reactive value is
called a *behavior*.

A constant reactive value can be constructed using `pure`:

    pure 15

This wire is the reactive value 15.  It does not depend on other
reactive values and does not change over time.  This suggests that there
is an applicative interface to wires, which is indeed the case:

    liftA2 (+) (pure 15) (pure 17)

This reactive value is the sum of two reactive values, each of which is
just a constant, 15 and 17 respectively.  So this is the constant
reactive value 32.  Let's spell out its type:

    myWire :: (Monad m, Num b) => Wire s e m a b
    myWire = liftA2 (+) (pure 15) (pure 17)

This indicates that $m$ is some kind of underlying monad.  As an
application developer you don't have to concern yourself much about it.
Framework developers can use it to allow wires to access environment
values through a reader monad or to produce something (like a GUI)
through a writer monad.

The wires we have seen so far are rather boring.  Let's look at a more
interesting one:

    time :: (HasTime t s) => Wire s e m a t

This wire represents the current local time, which starts at zero when
execution begins.  It does not make any assumptions about the time type
other than that it is a numeric type with a `Real` instance.  This is
enforced implicitly by the `HasTime` constraint.

The type of this wire gives some insight into the $s$ parameter.  Wires
are generally pure and do not have access to the system clock or other
run-time information.  The timing information has to come from outside
and is passed to the wire through a value of type $s$, called the *state
delta*.  We will learn more about this in the next section about
executing wires.

Since there is an applicative interface you can also apply `fmap` to a
wire to apply a function to its value:

    fmap (2*) time

This reactive value is a clock that is twice as fast as the regular
local time clock.  If you use system time as your clock, then the time
type $t$ will most likely be `NominalDiffTime` from `Data.Time.Clock`.
However, you will usually want to have time of type `Double` or some
other floating point type.  There is a predefined wire for this:

    timeF :: (Fractional b, HasTime t s, Monad m) => Wire s e m a b
    timeF = fmap realToFrac time

If you think of reactive values as graphs with the horizontal axis
representing time, then the `time` wire is just a straight diagonal line
and constant wires (constructed by `pure`) are just horizontal lines.
You can use the applicative interface to perform arithmetic on them:

    liftA2 (\t c -> c - 2*t) time (pure 60)

This gives you a countdown clock that starts at 60 and runs twice as
fast as the regular clock.  So it after two seconds its value will be
56, decreasing by 2 each second.


Testing wires
-------------

Enough theory, we wanna see some performance now!  Let's write a simple
program to test a constant (`pure`) wire:

    import Control.Wire
    import Prelude hiding ((.), id)

    wire :: (Monad m) => Wire s () m a Integer
    wire = pure 15

    main :: IO ()
    main = testWire (pure ()) wire

This should just display the value 15.  Abort the program by pressing
Ctrl-C.  The `testWire` function is a convenience to examine wires.  It
just executes the wire and continuously prints its value to stdout:

    testWire ::
        (MonadIO m, Show b, Show e)
        => Session m s
        -> (forall a. Wire s e Identity a b)
        -> m c

The type signatures in Netwire are known to be scary. =) But like most
of the library the underlying meaning is actually very simple.
Conceptually the wire is run continuously step by step, at each step
increasing its local time slightly.  This process is traditionally
called *stepping*.

As an FRP developer you assume a continuous time model, so you don't
observe this stepping process from the point of view of your reactive
application, but it can be useful to know that wire execution is
actually a discrete process.

The first argument of `testWire` needs some explanation.  It is a recipe
for state deltas.  In the above example we have just used `pure ()`,
meaning that we don't use anything stateful from the outside world,
particularly we don't use a clock.  From the type signature it is also
clear that this sets `s = ()`.

The second argument is the wire to run.  The input type is quantified
meaning that it needs to be polymorphic in its input type.  In other
words it means that the wire does not depend on any other reactive
value.  The underlying monad is `Identity` with the obvious meaning that
this wire cannot have any monadic effects.

The following application just displays the number of seconds passed
since program start (with some subsecond precision):

    wire :: (HasTime t s) => Wire s () m a t
    wire = time

    main :: IO ()
    main = testWire clockSession_ wire

Since this time the wire actually needs a clock we use `clockSession_`
as the second argument:

    clockSession_ ::
        (Applicative m, MonadIO m)
        => Session m (Timed NominalDiffTime ())

It will instantiate $s$ to be `Timed NominalDiffTime ()`.  This type
indeed has a `HasTime` instance with $t$ being `NominalDiffTime`.  In
simpler words it provides a clock to the wire.  At first it may seem
weird to use `NominalDiffTime` instead of something like `UTCTime`, but
this is reasonable, because time is relative to the wire's start time.
Also later in the section about switching we will see that a wire does
not necessarily start when the program starts.


Constructing wires
------------------

Now that we know how to test wires we can start constructing more
complicated wires.  First of all it is handy that there are many
convenience instances, including `Num`.  Instead of `pure 15` we can
simply write `15`.  Also instead of

    liftA2 (+) time (pure 17)

we can simply write:

    time + 17

This clock starts at 17 instead of zero.  Let's make it run twice as
fast:

    2*time + 17

If you have trouble wrapping your head around such an expression it may
help to read `a*b + c` mathematically as $a(t) b(t) + c(t)$ and read
`time` as simply $t$.

So far we have seen wires that ignore their input.  The following wire
uses its input:

    integral 5

It literally integrates its input value with respect to time.  Its
argument is the integration constant, i.e. the start value.  To supply
an input simply compose it:

    integral 5 . 3

Remember that `3` really means `pure 3`, a constant wire.  The integral
of the constant 3 is $3 t + c$ and here $c = 5$.  Here is another
example:

    integral 5 . time

Since `time` denotes $t$ the integral will be $\frac{1}{2} t^2 + c$,
again with $c = 5$.  This may sound like a complicated, sophisticated
wire, but it's really not.  Surprisingly there is no crazy algebra or
complicated numerical algorithm going on under the hood.  Integrating
over time requires one addition and one division each frame.  So there
is nothing wrong with using it extensively to animate a scene or to move
objects in a game.

Sometimes categorical composition and the applicative interface can be
inconvenient, in which case you may choose to use the arrow interface.
The above integration can be expressed the following way:

    proc _ -> do
        t <- time -< ()
        integral 5 -< t

Since `time` ignores its input signal, we just give it a constant signal
with value `()`.  We name time's value $t$ and pass it as the input
signal to `integral`.


Intervals
---------

Wires may choose to produce a signal only for a limited amount of time.
We refer to those wires as intervals.  When a wire does not produce,
then it *inhibits*.  Example:

    for 3

This wire acts like the identity wire in that it passes its input signal
through unchanged:

    for 3 . "yes"

The signal of this wire will be "yes", but after three seconds it will
stop to act like the identity wire and will inhibit forever.

When you use `testWire` inhibition will be displayed as "I:" followed by
a value, the *inhibition value*.  This is what the $e$ parameter to
`Wire` is.  It's called the *inhibition monoid*:

    for :: (HasTime t s, Monoid e) => t -> Wire s e m a a

As you can see the input and output types are the same and fully
polymorphic, hinting at the identity-like behavior.  All predefined
intervals inhibit with the `mempty` value.  When the wire inhibits, you
don't get a signal of type $a$, but rather an inhibition value of type
$e$.  Netwire does not interpret this value in any way and in most cases
you would simply use `e = ()`.

Intervals give you a very elegant way to combine wires:

    for 3 . "yes" <|> "no"

This wire produces "yes" for three seconds.  Then the wire to the left
of `<|>` will stop producing, so `<|>` will use the wire to its right
instead.  You can read the operator as a left-biased "or".  The signal
of the wire `w1 <|> w2` will be the signal of the leftmost component
wire that actually produced a signal.  There are a number of predefined
interval wires.  The above signal can be written equivalently as:

    after 3 . "no" <|> "yes"

The left wire will inhibit for the first three seconds, so during that
interval the right wire is chosen.  After that, as suggested by its
name, the `after` wire starts acting like the identity wire, so the left
side takes precedence.  Once the time period has passed the `after` wire
will produce forever, leaving the "yes" wire never to be reached again.
However, you can easily combine intervals:

    after 5 . for 6 . "Blip!" <|> "Look at me..."

The left wire will produce after five seconds from the beginning for six
seconds from the beginning, so effectively it will produce for one
second.  When you animate this wire, you will see the string "Look at
me..." for five seconds, then you will see "Blip!" for one second, then
finally it will go back to "Look at me..." and display that one forever.


Events
------

Events are things that happen at certain points in time.  Examples
include button presses, network packets or even just reaching a certain
point in time.  As such they can be thought of as lists of values
together with their occurrence times.  Events are actually first class
signals of the `Event` type:

    data Event a

For example the predefined `never` event is the event that never occurs:

    never :: Wire s e m a (Event b)

As suggested by the type events contain a value.  Netwire does not
export the constructors of the `Event` type by default.  If you are a
framework developer you can import the `Control.Wire.Unsafe.Event`
module to implement your own events.  A game engine may include events
for key presses or certain things happening in the scene.  However, as
an application developer you should view this type as being opaque.
This is necessary in order to protect continuous time semantics.  You
cannot access event values directly.

There are a number of ways to respond to an event.  The primary way to
do this in Netwire is to turn events into intervals.  There are a number
of predefined wires for that purpose, for example `asSoonAs`:

    asSoonAs :: (Monoid e) => Wire s e m (Event a) a

This wire takes an event signal as its input.  Initially it inhibits,
but as soon as the event occurs for the first time, it produces the
event's last value forever.  The `at` event will occur only once after
the given time period has passed:

    at :: (HasTime t s) => t -> Wire s e m a (Event a)

Example:

    at 3 . "blubb"

This event will occur after three seconds, and the event's value will be
"blubb".  Using `asSoonAs` we can turn this into an interval:

    asSoonAs . at 3 . "blubb"

This wire will inhibit for three seconds and then start producing.  It
will produce the value "blubb" forever.  That's the event's last value
after three seconds, and it will never change, because the event does
not occur ever again.  Here is an example that may be more
representative of that property:

    asSoonAs . at 3 . time

This wire inhibits for three seconds, then it produces the value 3 (or a
value close to it) forever.  Notice that this is not a clock.  It does
not produce the current time, but the `time` at the point in time when
the event occurred.

To combine multiple events there are a number of options.  In principle
you should think of event values to form a semigroup (of your choice),
because events can occur simultaneously.  However, in many cases the
actual value of the event is not that interesting, so there is an easy
way to get a left- or right-biased combination:

    (at 2 <& at 3) . time

This event occurs two times, namely once after two seconds and once
after three seconds.  In each case the event value will be the
occurrence time.  Here is an interesting case:

    at 2 . "blah" <& at 2 . "blubb"

These events will occur simultaneously.  The value will be "blah",
because `<&` means left-biased combination.  There is also `&>` for
right-biased combination.  If event values actually form a semigroup,
then you can just use monoidal composition:

    at 2 . "blah" <> at 2 . "blubb"

Again these events occur at the same time, but this time the event value
will be "blahblubb".  Note that you are using two Monoid instances and
one Semigroup instance here.  If the signals of two wires form a monoid,
then wires themselves form a monoid:

    w1 <> w2 = liftA2 (<>) w1 w2

There are many predefined event-wires and many combinators for
manipulating events in the `Control.Wire.Event` module.  A common events
is the `now` event:

    now :: Wire s e m a (Event a)

This event occurs once at the beginning.


Switching
---------

We still lack a meaningful way to respond to events.  This is where
*switching* comes in, sometimes also called *dynamic switching*.  The
most important combinator for switching is `-->`:

    w1 --> w2

The idea is really straightforward:  This wire acts like `w1` as long as
it produces.  As soon as it stops producing it is discarded and `w2`
takes its place.  Example:

    for 3 . "yes" --> "no"

In this case the behavior will be the same as in the *intervals*
section, but with two major differences:  Firstly when the first
interval ends, it is completely discarded and garbage-collected, never
to be seen again.  Secondly and more importantly the point in time of
switching will be the beginning for the new wire.  Example:

    for 3 . time --> time

This wire will show a clock counting to three seconds, then it will
start over from zero.  This is why we usually refer to time as *local
time*.

Recursion is fully supported.  Here is a fun example:

    netwireIsCool =
        for 2 . "Once upon a time..." -->
        for 3 . "... games were completely imperative..." -->
        for 2 . "... but then..." -->
        for 10 . ("Netwire 5! " <> anim) -->
        netwireIsCool

      where
        anim =
            holdFor 0.5 . periodic 1 . "Hoo..." <|>
            "...ray!"